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

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

AFAICS, it would only shift code around. The interceptor invocation is supposed to to be synchronous. So you can make an async call and block in the interceptor or have an API in JBossWeb that starts/stops a context synchronously. I think the latter is the better option. On 07/23/2012 11:18 AM, David Bosschaert wrote: > It would be nice if there was a single code path to start the > bundles. It wouldn't be an option for the interceptor to start the > bundle asynchronously (possibly with a callback when its done) so > that the deployment can continue no matter what? > > Cheers, > > David > > On 20/07/2012 22:48, Thomas Diesler wrote: >> 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 >> >

Registering the BundleContext of the WAB is work that needs to be done after the bundle has started. So it belongs in a DUP that comes after the BundleActivateProcessor. If not done so already you can make the WebServer context a deployment dependency onto the next phase. Your DUP would then have a guarantee that both the bundle and the WebServer context services are UP. The values of those services can be obtained from the DU. There should be no need to register listeners. Re listener: Generally - the listener should be registered on the service that it belongs (not the phase service). The listener should also have a code path for failure. If there is nothing to do in case of failure - the listener should say so. --thomas On 07/23/2012 05:33 PM, David Bosschaert wrote: > For AS7-5199 I need to register the ServletContext as an OSGi service > as soon as the bundle is started. > The synchronous case in the Interceptor is easy, but regarding the > async one, is this the best way of doing this? > > https://github.com/bosschaert/jboss-as/commit/e77f1fb615414f2d6fa29bca6d1... > > > Thanks, > > David > > On 23/07/2012 10:25, Thomas Diesler wrote: >> AFAICS, it would only shift code around. The interceptor invocation >> is supposed to to be synchronous. So you can make an async call and >> block in the interceptor or have an API in JBossWeb that >> starts/stops a context synchronously. I think the latter is the >> better option. >> >> On 07/23/2012 11:18 AM, David Bosschaert wrote: >>> It would be nice if there was a single code path to start the >>> bundles. It wouldn't be an option for the interceptor to start the >>> bundle asynchronously (possibly with a callback when its done) so >>> that the deployment can continue no matter what? >>> >>> Cheers, >>> >>> David >>> >>> On 20/07/2012 22:48, Thomas Diesler wrote: >>>> 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 >>>> >>> >> >