PicoWeb: "Already disposed" exception with Startable request-scope components

[Daniel Wellman]

I have a question about how the WebappComposer works with request containers
that have components with lifecycle behaviors. Do request-scope components
support the Startable behavior in PicoWeb 2?

I've tried adding such a component to my WebappComposer but get an "Already
disposed" exception on my second HTTP request -- it fails when trying to
start the request-level Pico in PicoServletContainerFilter.

In the sample PicoWeb2 app using WebWork 2, I added a request-composed
component called RequestLogger, which implements Startable as below

public class RequestLogger implements Startable {
public void log(String message) {
System.out.println(new java.util.Date() + " " + message);
}

public void start() {
System.out.println(RequestLogger.class + " starting.");
}

public void stop() {
System.out.println(RequestLogger.class + " stopping.");
}
}

And I added RequestLogger to the CheeseInventory action to print a message.
I added the component to my WebappComposer's composeRequest() method.

When I run the application, the first request works as expected, but the
second request fails trying to start the request container with an "Already
disposed" exception.

First request works as expected:

class org.nanocontainer.nanowar.sample.RequestLogger starting.
Wed Nov 12 21:13:58 EST 2008 Found 1 cheeses.
class org.nanocontainer.nanowar.sample.RequestLogger stopping.


Second request prints:

Nov 12, 2008 9:14:07 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet action threw exception
java.lang.IllegalStateException: Already disposed
at org.picocontainer.behaviors.Stored.start(Stored.java:96)
at
org.picocontainer.DefaultPicoContainer.startAdapters(DefaultPicoContainer.java:887)
at
org.picocontainer.DefaultPicoContainer.start(DefaultPicoContainer.java:631)
at
org.picocontainer.web.PicoServletContainerFilter.doFilter(PicoServletContainerFilter.java:95)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:595)

When I debug, I find that in the second request's invoation of
DefaultPicoContainer's startAdapters() method, the list of Behaviors
includes my request object, which is marked as disposed but not started. I
trace through first request and find that indeed the component
is started, stopped, then disposed.

I'm using PicoWeb 2.1 with PicoContainer & Gems 2.6, using WebWork 2.1
(though the same behavior happens with WebWork 2.2) and Tomcat 5.5.

Thanks for your advice!

Cheers,
Dan

[Paul Hammant]

There was a bug that's been fixed in the latest Subversion commits.
I'll send you a jar off the list for you to try out.

Regards,

- Paul

Post by Daniel Wellman
I have a question about how the WebappComposer works with request containers
that have components with lifecycle behaviors. Do request-scope components
support the Startable behavior in PicoWeb 2?
I've tried adding such a component to my WebappComposer but get an "Already
disposed" exception on my second HTTP request -- it fails when
trying to
start the request-level Pico in PicoServletContainerFilter.
In the sample PicoWeb2 app using WebWork 2, I added a request-composed
component called RequestLogger, which implements Startable as below
public class RequestLogger implements Startable {
public void log(String message) {
System.out.println(new java.util.Date() + " " + message);
}
public void start() {
System.out.println(RequestLogger.class + " starting.");
}
public void stop() {
System.out.println(RequestLogger.class + " stopping.");
}
}
And I added RequestLogger to the CheeseInventory action to print a message.
I added the component to my WebappComposer's composeRequest() method.
When I run the application, the first request works as expected, but the
second request fails trying to start the request container with an "Already
disposed" exception.
class org.nanocontainer.nanowar.sample.RequestLogger starting.
Wed Nov 12 21:13:58 EST 2008 Found 1 cheeses.
class org.nanocontainer.nanowar.sample.RequestLogger stopping.
Nov 12, 2008 9:14:07 PM
org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet action threw exception
java.lang.IllegalStateException: Already disposed
at org.picocontainer.behaviors.Stored.start(Stored.java:96)
at
org
.picocontainer
.DefaultPicoContainer.startAdapters(DefaultPicoContainer.java:887)
at
org
631)
at
org
.picocontainer
.web
95)
at
org
.apache
.catalina
.core
215)
at
org
.apache
.catalina
.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org
.apache
210)
at
org
.apache
174)
at
org
.apache
.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org
.apache
.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org
.apache
108)
at
org
151)
at
org
870)
at
org.apache.coyote.http11.Http11BaseProtocol
665)
at
org
.apache
528)
at
org
.apache
.tomcat
.util
.net
.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:595)
When I debug, I find that in the second request's invoation of
DefaultPicoContainer's startAdapters() method, the list of Behaviors
includes my request object, which is marked as disposed but not started. I
trace through first request and find that indeed the component
is started, stopped, then disposed.
I'm using PicoWeb 2.1 with PicoContainer & Gems 2.6, using WebWork 2.1
(though the same behavior happens with WebWork 2.2) and Tomcat 5.5.
Thanks for your advice!
Cheers,
Dan
--
View this message in context: http://www.nabble.com/PicoWeb%3A-%22Already-disposed%22-exception-with-Startable-request-scope-components-tp20480963p20480963.html
Sent from the NanoContainer - PicoContainer - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Mauro Talevi]

Post by Paul Hammant
There was a bug that's been fixed in the latest Subversion commits.
I'll send you a jar off the list for you to try out.

I've deployed new snapshots to

http://snapshots.repository.codehaus.org/org/picocontainer/web/

Cheers



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Daniel Wellman]

OK, I downloaded the 2008-11-14 PicoContainer 2.7 snapshot that Mauro
deployed last night and the bug is gone. I'm using it with the released
PicoWeb 2.1 and it's working fine.

Thank you for posting the fix!

Dan

Post by Mauro Talevi

Post by Paul Hammant
There was a bug that's been fixed in the latest Subversion commits.
I'll send you a jar off the list for you to try out.

I've deployed new snapshots to
http://snapshots.repository.codehaus.org/org/picocontainer/web/
Cheers
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Paul Hammant]

Daniel,

Kewl :) Mauro and I are going to get some pairing in next week,
maybe with a release following that.

- Paul

Post by Daniel Wellman
OK, I downloaded the 2008-11-14 PicoContainer 2.7 snapshot that Mauro
deployed last night and the bug is gone. I'm using it with the released
PicoWeb 2.1 and it's working fine.
Thank you for posting the fix!
Dan

Post by Mauro Talevi

Post by Paul Hammant
There was a bug that's been fixed in the latest Subversion commits.
I'll send you a jar off the list for you to try out.

I've deployed new snapshots to
http://snapshots.repository.codehaus.org/org/picocontainer/web/
Cheers
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

--
View this message in context: http://www.nabble.com/PicoWeb%3A-%22Already-disposed%22-exception-with-Startable-request-scope-components-tp20480963p20500101.html
Sent from the NanoContainer - PicoContainer - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Nick Drew]

hi

I've noticed that the HiddenImplementation behaviour doesn't play
particularly nicely with Lifecycle management

If a delegate component adapter supports lifecycle strategy, and the
HiddenImplementation behaviour is asked to dispose it delegates
correctly, except it passes the proxy instance to the delegate, rather
than the instance the delegate created.

I can't override this behaviour to do the right thing, because
createProxy is private, and there is an anonymous inner class that
holds the delegate instance.

Cheers

Nick

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Paul Hammant]

OK, Nick lemme take a look. tell me what methods to turn to protected
at the very least.

Lifecycle capability for threadlocalised containers got improved again
on monday. A bug you'd most likely not hit yet.

Regards,

- Paul

Post by Nick Drew
hi
I've noticed that the HiddenImplementation behaviour doesn't play
particularly nicely with Lifecycle management
If a delegate component adapter supports lifecycle strategy, and the
HiddenImplementation behaviour is asked to dispose it delegates
correctly, except it passes the proxy instance to the delegate,
rather than the instance the delegate created.
I can't override this behaviour to do the right thing, because
createProxy is private, and there is an anonymous inner class that
holds the delegate instance.
Cheers
Nick
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Paul Hammant]

Nick,

Do you think this would be better for ImplementationHiding ? :

@SuppressWarnings("unchecked")
protected T createProxy(Class[] interfaces, final PicoContainer
container, final ClassLoader classLoader) {
return (T) Proxy.newProxyInstance(classLoader, interfaces,
new InvocationHandler() {
public synchronized Object invoke(final Object proxy,
final Method method, final Object[] args) throws Throwable {
return
invokeMethod(getDelegate().getComponentInstance(container,
NOTHING.class), method, args, container);
}
});
}

I'm going to try to find a reliable test scenario for the bug...


Regards,

- Paul

Post by Paul Hammant
OK, Nick lemme take a look. tell me what methods to turn to
protected at the very least.
Lifecycle capability for threadlocalised containers got improved
again on monday. A bug you'd most likely not hit yet.
Regards,
- Paul

Post by Nick Drew
hi
I've noticed that the HiddenImplementation behaviour doesn't play
particularly nicely with Lifecycle management
If a delegate component adapter supports lifecycle strategy, and
the HiddenImplementation behaviour is asked to dispose it delegates
correctly, except it passes the proxy instance to the delegate,
rather than the instance the delegate created.
I can't override this behaviour to do the right thing, because
createProxy is private, and there is an anonymous inner class that
holds the delegate instance.
Cheers
Nick
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email