I looked into this and it is indeed necessary to have an async and sync
code path.
During deployment *nothing* can block. The BundleActivateProcessor calls
into the framework to start the bundle. This synchronously invokes the
lifecycle interceptor chain, the WebContextLifecycleInterceptor call
into ContextActivator.start(), which must synchronously wait for the
service to come up (otherwise there is no guarantee the the context can
process requests when the bundle is started). When the
BundleActivateProcessor does this it is not guranteed that all
dependedencies of the web context service are available - they might be
added by later DUPs. Voila you you get a timeout (which is better than
deadlock)
if (controller.getMode() == Mode.NEVER) {
controller.setMode(Mode.ACTIVE);
result = awaitStateChange(State.UP, timeout, unit);
}
During deployment the code above will do nothing because the mode has
already been set to ACTIVE. It becomes effective when the bundle gets
stoped/started on a later management or API calls.
I changed the comments to hopefully be more clear about this
/**
* Start the web context asynchronously.
*
* This would happen during OSGi webapp deployment.
*
* No DUP can assume that all dependencies are available to
make a blocking call
* instead it should call this method.
*/
public synchronized void startAsync() {
/**
* Start the web context synchronously.
*
* This would happen when the OSGi webapp gets explicitly started.
*/
public synchronized boolean start(long timeout, TimeUnit unit)
throws TimeoutException {
/**
* Stop the web context synchronously.
*
* This would happen when the OSGi webapp gets explicitly stopped.
*/
public synchronized boolean stop(long timeout, TimeUnit unit) {
On 07/20/2012 10:49 PM, Thomas Diesler wrote:
Actually, on second thought startAsync should not be necessary. It
already happens in the WarDeploymentProcessor.
Thanks for spotting this - I'll run a few tests with this removed.
cheers
-thomas
On 07/20/2012 10:19 PM, Thomas Diesler wrote:
> Does it not say this?
>
> /**
> * Start the web context asynchronously.
> * This would happen during normal WAR deployment
> */
> public synchronized void startAsync() {
>
> /**
> * Start the web context synchronously.
> * This would happen when an OSGi Web Application Bundle (WAB)
> transitions to {@link Bundle#ACTIVE}
> * i.e. the WAB starts
> */
> public synchronized boolean start(long timeout, TimeUnit unit)
> throws TimeoutException {
>
> On 07/20/2012 07:38 PM, David Bosschaert wrote:
>> Hi all,
>>
>> While looking at the WebContextActivationProcessor [1] I see that the
>> ContextActivator can get started in 2 places: in the deploy() method and
>> in the LifecycleInterceptor.
>> I'd like to understand when each of these are used? Is it not possible
>> to do this in a single place?
>>
>> Thanks,
>>
>> David
>>
>> [1]
>>
https://github.com/bosschaert/jboss-as/blob/master/osgi/web/src/main/java...
>>
>> _______________________________________________
>> jboss-osgi-dev mailing list
>> jboss-osgi-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-osgi-dev
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx