On Mar 22, 2013, at 10:47 AM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
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(a)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