the patch set is ready for review: #3117
This functionality is constraint to osgi only. If there is a bundle
deployment that cannot resolve (possibly the user said so) I'll set the
FIRST_MODULE_USE phase to initial NEVER. The deployment hangs in the
configure module phase and awaits an external trigger. The bundle is
metadata valid and in state Bundle.INSTALLED.
A Bundle.start() operation sets up a service tracker and activates the
deferred phase. this only succeeds if the bundle can get resolved and
has a Module attached. The bundle deployment proceeds through the phases
and activates. If there is failure in any of the tracked services
Bundle.start() will fail with the root cause and the FIRST_MODULE_USE
phase is set back to NEVER - this is a partial undeploy. After
correcting the problem the user can re-attempt a Bundle.start().
In case of bundles contained in an EAR, I set the FIRST_MODULE_USE phase
of the EAR to PASSIVE.
It is possible that some DUPs dont support repeated deploy calls (yet).
In which case they use
with the number of attempts they do support (see
Some techs that support bundle deployments (i.e.
web,jaxrs,jaxws,jpa,cdi,ejb3) may still need more work to support
restart after failure. This can be done on a case by case basis.
Generally DUPs can now assume that a module is attached for a host
bundle deployment. In case of an unresolved bundle deployment we don't
miss the work they do any more. However, we still need the module not
null checks because bundle fragment deployments never have a module.
They attach to a host and use that class loader.
JBoss OSGi Lead
JBoss, a division of Red Hat