RE: [picocontainer-dev] NanoWAR and session madness in Tomcat 5

Ok, forget my previous reply.  I don't know why I didn't see it before, 
but, in fact, I am now seeing the app scope container causing a 
serialization exception.  The app still never fails to start because of a 
race condition, so I don't know what that's all about, but I do, indeed see 
problems when I add a component to the app scope that isn't serializable.

Does the fix involve continuing to let the session container keep its state 
across serialization/deserialization?

Jake

At 09:24 PM 12/30/2005 -0600, you wrote:
 >At 04:27 PM 12/30/2005 -0800, you wrote:
 > >> We already know that it works with Tomcat in at least one case; using the
 > >> groovy pico syntax rather than the builder syntax (maybe not with the
 > >> context container, because I don't store a component in the context
 > >> container,
 > >
 > >Correct, that's probably why it works for you.
 > >
 >
 >Well, just to test it out, I registered a component in the context
 >scope.  The class that I registered does *not* implement Serializable.  I
 >was able to use the component just fine.  Then I restarted my context to
 >see what would happen with serialization.  No problems at all.  The counter
 >stored in the session kept its count just fine.  So, I guess there goes
 >that theory of why it is working for me, but not for you.
 >
 > >> but with the request container, which we also know fails
 > >> serialization when using the builder syntax, so I presume it's the same
 > >> problem being discussed).  And that's with no changes whatsoever to
 > >> ServletContextListener.
 > >
 > >Right, but for me the non-builder script actually failed on my system
 > >because of a race condition.
 > >
 >
 >I've never, ever, seen a race condition.  Are you saying that the sample
 >app that I provided failed for you with the pico syntax, or your own
 >app?  I've never had a problem.  I'm using Tomcat 5.5.14.  What version are
 >you using?  I don't know why that would make a difference for a race
 >condition, but, again, it's never failed for me.
 >
 > >Once I got the race condition fixed, then both behaved identically for me.
 > >
 >
 >Is that checked in?  I've only ever had problems with the builder syntax.
 >
 > >I think actually what was happening was that the SessionContainer wasn't
 > >getting properly hooked into the app container under the "straight syntax",
 > >which is why you didn't get the serialization errors.
 > >
 >
 >Ok, but I look up the context container view the request container.  So,
 >it's got to go through the session container to get to the top level
 >context container, no?  I get a handle on my context component just fine.
 >
 > >But you actually SHOULD have gotten the serialization error even under
 > >straight syntax. (No, I'm not making it up! ;) )
 > >
 >
 >But based on what you said above, the pico syntax should have failed for me
 >100% of the time anyway because of a race condition.  The fact that I'm
 >telling you that the pico syntax works for me but the builder syntax
 >doesn't means that there is some disconnect here.  What you say doesn't
 >work, works for me.
 >
 > >> If modifying ServletContextListener makes it all
 > >> work with all syntaxes, that would be great.  However, the fact that it
 > >> works with the pico syntax with no changes means that the change would
 > >> simply be masking a more fundamental issue that should probably be solved
 > >> first.
 > >
 > >My guess is that I think it only superficially worked for you.   (My 
bet was
 > >that because you never actually used the App container, your dependency
 > >checks never failed.)
 > >
 >
 >Ok, I have a component registered in the app container, and everything
 >works.  Now, granted, no other container has a dependency on this component
 >in the app container.  It's just a dummy class that sitting in there that
 >doesn't implement Serializable.  However, given that the session container,
 >according to you, is serializing the app container along with it during
 >session serialization, then it shouldn't matter whether there is a
 >dependency of the session component on the app component.  The hierarchy of
 >the containers is the theorized problem.  If there is a class in the app
 >container that isn't serializable, then based on what you are saying, I
 >should see serialization errors upon app/server restart.  In fact, I see no
 >errors.  Everything works just fine.
 >
 > >Does this clarify??
 > >
 >
 >No, it's mudding the waters significantly.  How can we have such different
 >environments that my stuff works and yours doesn't, when the app we're
 >running is pretty much identical (you are testing my picoservlet test app,
 >right?).?
 >
 > >
 > >-Mike
 >
 >Jake
 >
 >
 >