I implement the first cut of this as we talked about.
The DeferredModuleUseProcessor adds a the module service as a dependency
on the next phase, which is FISRT_MODULE_USE. This is actually something
I previously already did for resolved bundles - now I do it always in
The DeploymentUnitPhaseService makes Phase.FISRT_MODULE_USE passive if
it sees explicitly named services in
The processing is currently limited to OSGi only and this patch should
not effect other deployment types. The OSGi testsuite passes completely
with a few deployments hanging in Phase.FISRT_MODULE_USE before they
triggered to proceed by an explicit API call which resolves the bundle
and hance makes the module service available.
* Think about whether Phase.FISRT_MODULE_USE should always depend on the
* Remove all module == null checks in FISRT_MODULE_USE DUPs and after.
JBoss OSGi Lead
JBoss, a division of Red Hat
I will be on PTO from this Thursday and get back on 15 October (although I will be at home from the 12th sometime). I won't have VPN access but if anything urgent comes up, get in touch on kabir_at_home(a)yahoo.co.uk.
We've worked out the rough outline of how graceful shutdown will work in
The process of graceful shutdown actually is reflected by a number of
1. Running - all services acting normally
2. Suspending - services refuse new "permits" (see below), existing
permits are allowed to be retained (and threads running under such a
permit may still acquire new permits)
3. Suspended - no permits are present and none may be issued
4. Shutting Down - our existing server stop process / reload admin mode
The following transitions are allowed:
1. Running → Suspending: Transition occurs at user request (to suspend
or gracefully shut down).
2. Suspending → Suspended: Transition occurs when all permits are cleared.
3. Suspending → Running: Transition occurs at user request (to exit
suspend mode or cancel graceful shutdown before it completes).
4. Suspended → Running: Transition occurs at user request (to exit
5. Suspended → Shutting Down: Transition occurs automatically (if a
graceful shutdown was requested) or at user request (if a shut down
request of any kind is entered in the Suspended state).
6. Running → Shutting Down: Transition occurs at user request (to shut
down the server "un-gracefully").
7. Suspending → Shutting Down (User aborts a graceful shutdown)
These "permits" are issued by the "Shutdown Manager", whose job is to
manage these states. They are issued corresponding to the following events:
1. The invocation of an EJB method
2. The creation of a web session
3. A creation of a transaction
4. MessageEndpoint and WorkManager aquire permit allowing for release()
from a thirdparty to indicate connection close.
When a permit cannot be issued due to the server shutting down, a
standard exception message should be produced so that the user can see a
familiar error message regardless of what mechanism is used to access
jboss-as7-dev mailing list
I have a module defined like this (currently in master with main and
<module xmlns="urn:jboss:module:1.1" name="org.jboss.as.jsf-injection">
<module name="com.sun.jsf-impl"/> <----- this needs to be dynamic
Inside a DeploymentUnitProcessor, the module above is added to the
ModuleSpecification along with the module for the selected JSF
implementation. The problem I have is that the JSF Injection code is
the same for any Mojarra implementation. But to support multiple
implementations I need to declare a separate jsf-injection module with a
hard-coded dependency on each implementation installed.
If I could create a module dynamically and dynamically add its
dependencies then there would be no need to create more and more modules
containing the same jsf-injection jar.
I've been looking at the JBoss Modules API and I don't see how to do
this. Is it possible?