Note that it would be nice to eventually allow unscoped plans to be able to share artifacts, but this would involve some reference counting and garbage collection and is a little complicated when we consider how lifecycle operations on plans would affect shared artifacts. Perhaps we'll leave this until Virgo implements the OSGi subsystems RFC 152.
Let me explain a scenario I have. May be someone can suggest how I can achieve this:
I wanted to create common services like the OSGI compendium services. One such "utility" service I have is an incident manager. Its a glorified logging system that has emails sent to "event" subscribers based on custom event processing/correlation. [There are other systems like this available but they are primarily focused on the IT user. I had to tailor it to the business user who need to be notified via "business friendly" email.]
Several other plans want to ensure that the incident manager is available for it to run. If I create scoped plan and include the incident manager in it, Virgo will attempt to create new instances of the incident manager for each plan. Since incident manager plan has a web context and a TCP port it listens on for non-Java apps to send incidents, the second instance creation will fail. Hence I thought of creating unscoped plans. But then too the second installation fails because the incident manager plan is already installed.
There are lots of other scenarios, for example, if I want Virgo to be an ESB platform, I will need Singleton services like the JMS provider or Hazelcast instance, etc.
I can see based on Glyn's description why the implementation is the way it is now. Are there other ways that I can achieve my goal?
You could deploy such common utilities using the initialArtifacts property in the user region configuration file. See the User Guide for details. This would ensure the utilities are deployed before your (other) applications. The applications would then not list these utilities in their plans. The main downside is that the dependency is implicit in the applications' plans.
This is working great! Implicit dependency is not a problem in my case. I can ensure that through deployment/installation automation. I noticed that above the initialArtifacts property there is a comment stating Quote:
# the next line must not be broken with back-slashes
I tried breaking the line with back-slashes and it works fine.