RE: [picocontainer-dev] NanoWAR and session madness in Tomcat 5
Jacob Kjome <[email protected]>
| Newsgroups | gmane.comp.java.picocontainer.devel |
|---|---|
| Message-ID | <[email protected]> |
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