Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/ser vices/statemanager BaseStateManagerService.java JetspeedHttpStateManagerS ervice.java JetspeedStateManagerService.java

[Santiago Gala <sg...@hisitech.com>]

Glenn Golden wrote:

>Paul, Developers,
>
>I ran tests of these services before I checked them in, and we are using
>them in our project.  I don't have time right now to create proper
>check-in-able unit tests, but could do so later.
>
>These are tricky to test, as they must be run within a running server with
>an active servlet container providing http sessions; tests require two
>different sessions and actual http requests coming in... I also need to
>expire an http session in the tests... I'd be interested to see how this can
>be unit tested.
>
>I tested it by writing a portlet that will invoke tests against the service
>- which I can run from two different browsers so as to get the two different
>sessions...
>
>Anyway, there's something fishy about the JetspeedHttpStateManagerService,
>although it passed all my tests!  It doesn't seem to provide the state
>information created by on servlet to another servlet, even though they
>should be in the same session.  Haven't tracked this one down yet.
>  
>
If the two servlets are in different contexts, it is bound to fail, as 
the variable storing the information is a static member of a class, and 
two classes are the same if they have the same name *and* the same 
classloader, and this is guaranteed *not* to be true in different 
contexts (different classloaders), unless you put the .jar containing 
the class in a common context, like TOMCAT_HOME/lib in tomcat 3.2.X, or 
TOMCAT_HOME/common or shared in Tomcat 4.0

I wonder if you thought about using ThreadLocal variables for this 
feature. I had been thinking about this solution for storing 
request-oriented info. It was rather slow in jdk1.2, but it seems it has 
improved in recent java VMs. Putting the rundata in a ThreadLocal 
variable at the start of the request processing, and removing it at the 
end will achieve rather similar results to what you are doing here.

>I'll resolve that before I enable it as the default for Jetspeed (which is
>my plan) and start to change parts of jetspeed to use this service.
>  
>
Which parts will be using this?

While it can be useful, it makes strong assumptions about the servlet 
container (one thread per request). These assumptions are currenty true 
for all containers, though.

>- Glenn
>  
>
Regards,
   Santiago


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>