You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Glenn Golden <gg...@umich.edu> on 2002/06/17 06:06:57 UTC
RE: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/ser
vices/statemanager BaseStateManagerService.java JetspeedHttpStateManagerS
ervice.java JetspeedStateManagerService.java
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.
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.
- Glenn
> -----Original Message-----
> From: Paul Spencer [mailto:paulsp@apache.org]
> Sent: Tuesday, June 11, 2002 10:48 AM
> To: Jetspeed Developers List
> Subject: Re: cvs commit:
> jakarta-jetspeed/src/java/org/apache/jetspeed/services/statema
> nager BaseStateManagerService.java
> JetspeedHttpStateManagerService.java JetspeedStateManagerService.java
>
>
> Glenn,
> I did not see a test case.
>
> Paul Spencer
>
> ggolden@apache.org wrote:
>
> > ggolden 2002/06/10 12:57:18
> >
> > Modified: src/java/org/apache/jetspeed/services/statemanager
> > JetspeedStateManagerService.java
> > Added: src/java/org/apache/jetspeed/services/statemanager
> > BaseStateManagerService.java
> > JetspeedHttpStateManagerService.java
> > Log:
> > Introducing the BaseStateManagerService, an abstract
> implementation
> > of the StateManagerService. JetspeedStateManagerService
> re-organized
> > to extend this.
> >
> > Introducing JetspeedHttpStateManagerService, an
> implementation of the
> > StateManagerService which stores attribute sets (for each
> session state)
> > in the actual HTTP Session, and has automatic cleanup of
> attributes when
> > the session invalidates.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/ser
vices/statemanager BaseStateManagerService.java JetspeedHttpStateManagerS
ervice.java JetspeedStateManagerService.java
Posted by 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>
Re: cvs commit: jakarta-jetspeed/src/java/org/apache/jetspeed/ser vices/statemanager BaseStateManagerService.java JetspeedHttpStateManagerS ervice.java JetspeedStateManagerService.java
Posted by Paul Spencer <pa...@apache.org>.
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.
>
Use Cactus for this type of testing.
> 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...
>
I would prefer a Cactus test because it can be executed via ant.
> 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.
>
> 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.
>
> - Glenn
>
Paul Spencer
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>