[jboss-as7-dev] Deployment restarts

[Thomas Diesler]

I think we need to have a conversation on how this is generally supposed to work.

Option #1

Undeployment of a deployment that others dependent on (automatically) takes the transitive graph of dependent deployments down. If so, we need to look at when restart is attempted. Should this be done automatically when the named dependency reappears? This is more or less what we have today.

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.

------

The OSGi model is option #2 and can IMHO not be mapped cleanly to what we have in AS today. Even if we fix the DUP issue it will not work because bundle A that depends on bundle B should not be effected when B gets undeployed (i.e. BundleActivator.stop() must not be called for A). Some time back I suggested the notion of "lazy service dependency" 

* A depends on B
* A stays up even when B goes down
* B must have come up at least once for A to come up

I suggest we wait for the outcome of the FY2014 planning in Newcastle. If it should be decided that AS is supposed to provided proper OSGi support, we can revisit this issue together with

* deployment start/stop
* deployment update
* wiring refresh

cheers
--thomas


On Mar 22, 2013, at 8:08 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> I have done up a patch that should allow deployment restarts to work, basically it just detects if the deployment has already started, and forces a complete restart, rather than attempting to re-run the DUP's.
> 
> https://github.com/jbossas/jboss-as/pull/4268
> 
> Unfortunately this breaks DeferredResolveTestCase, because a new instance of DeferredFailActivator is created. I'm not really sure how best to solve this, as I am not sure what the allowed semantics are here with regard to OSGi.
> 
> Do you have any ideas about how to deal with this?
> 
> Stuart

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx