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
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx