Thomas Diesler wrote:
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.
We only have half of this today. It takes down the dependent deployments, however it is not possible to restart them.
Yes, restart is attempted but the DUPs are not designed for it.
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.
------
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
That would actually not be that hard to implement. I think you could implement it using a service that depends on deployment B with mode PASSIVE, and when that service comes up it simply actives the deferred deployment A. This would be an OSGi only thing though.
This is an option we can explore. You mean that module phase services for OSGi deployments would not have module service dependencies coming from other deployments? I believe that access to "removal pending" bundles is limited to resource and class loading. Services associated with the uninstalled bundle are gone. AFAIU, undeploy of an in use bundle could roll back the phases down to FIRST_MODULE_USE (i.e. the Module stays available)
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
Ok, but I would really like to get this into EAP 6.1 if at all possible, as it does make inter deployment dependencies and class loader dependencies work a lot better.
I guess the read question is other than the failing test, does this actually cause real problems for OSGi, especially given that the current behavior means that half the time restarts won't work anyway.
It does cause real problems for OSGi, because the fundamental semantics of install/start/stop/uninstall is not mapped properly to deployment management operations. Bundle update is not implemented, neither is FrameworkWiring.refreshPackages().
IMHO, the best approach would be to look at this from the perspective of deployment management ops. When the required functionality is available at that level, the OSGi layer could simply use that.
Initially, we would need proper support for
start/stop operations. Undeploy, when given with a differentiator, should first stop the deployment and then depending on some criteria (i.e. in use wirings) continue the undeploy or not. If start/stop was supported properly it would be a matter of fixing individual DUPs and perhaps selectively disabling cleanup (i.e. a DUP could that needs the cleanup state to support start/stop could prevent the cleanup)
Stuart
cheers
--thomas
On Mar 22, 2013, at 8:08 AM, Stuart Douglas<sdouglas@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
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx