On Mar 22, 2013, at 9:56 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
Thomas Diesler wrote:
>>
>>>
>>> Options #2
>>>
>>> Undeployment of a deployment that others dependent on does not effect
>>> existing wiring. Dependent deployments continue to work and reference
>>> a stale deployment with associated module/classloader. Only if there
>>> are no users/wires to the undeployed - it can be removed completely.
>>> User interaction is needed to cause a rewiring.
>>>
>>
>> I think this is very problematic, as dependencies are not just class
>> loading dependencies but can also be dependencies on EJB's,
>> EntityManagers etc.
>
> Yes, OSGi uninstall is more like an intension to undeploy. We would need
> to look at whether this approach can be adopted for all deployment types
> or whether we need a differentiator that deployments can use if
> intension to undeploy is the the desired behaviour.
For non-OSGi dependencies undeploy is the correct behavior. It is the only way to get
anything close to consistent behaviour.
Is this really true? The thing that gets undeployed will have its services stopped other
stuff should track these services and react accordingly. Most likely taking the services
down that depend on the services that are now not available anymore. This would guarantee
service consistency. Classloading is different - its possible that a component has a wire
to the undeployed module and should be able to continue to use that module. A class loader
dependency is not equivalent to a service dependency IMHO. Think of a utility class in the
undeployed module that is being used. Going through an alternative code path nay require
to load more classes from that Module - this should work.
I'd say a module/classloader should only get removed if it has no users any more. At
implementation level it would require an undeploy to wait in the module phase until its
usage count drops to zero.
For now I will re-work my patch so that the deployment only restarts if the re-deployment
is a result of an inter-deployment dependency, rather than an OSGi deferred resolve.
Stuart
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx