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