tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Basham <bbas...@stillsecure.com>
Subject Re: Creating a custom session manager -- SOLVED
Date Wed, 10 Jan 2007 20:34:38 GMT
Hello again,

Chuck Caldarale solved my configuration problem.  I then created the 
code to solve the "shared session" manager problem.  I created a test 
(see attached JAR file) with the solution code which I thought I would 
share with the Tomcat community in case someone else needs to solve this 
problem.  (Or to compare with your own solution)

Here's the design:  I created two classes: SharedSessionManager (SSM) 
and SharedSessionRequestValve (SSRV).  The SSM class is a decorator that 
delegates most methods to a StandardManager object.  The SSM keeps track 
of a mapping between a global ID (a hijacked session ID) and the 
container-created session object.  The SSM.createSession method attempts 
to locate the global session; use that if it exists, otherwise delegate 
the creation to the standard manager.  The SSM.findSession method also 
attempts to locate the global session; use that if it exists or 
delegate.  All other methods delegate to the standard manager.

The global session is stored in SSM by the SSRV class.  The SSRV.invoke 
method does the following:
  1) If the GLOBALID cookie is set on the request, tell SSM to use this 
ID for the global session.
     1.1) If the GLOBALID exists but the associated session is invalid, 
then destroy the GLOBALID (start over)
  2) Pass the request to the next valve (ultimately to the webapp)
  3) Retrieve the JSESSIONID from the response
  4) If there was no GLOBALID cookie on the request, then hijack the 
container-created JSESSIONID as the GLOBALID
      4.1) Put the GLOBALID cookie (path=/) on the response
      4.2) Assign the container-created session to the GLOBALID within 
the SSM class

Both of these classes must reside in the $TOMCAT_HOME/server/ area; 
either as raw classes or in a JAR file.  It appears, they cannot be put 
in the common/ or shared/ area.

The last piece of the puzzle is that you need to declare both of these 
classes in the $TOMCAT_HOME/conf/context.xml file.

That's it.  Your webapps do not need any additional code or 
configuration to take advantage of this functionality.  However, note 
that *every* webapp will now share session objects.  It cannot be turned 
off for specific webapps.

The JAR attachment contains *all* of the necessary files and Ant build 
script.  It also includes the content (JSP files that contain a form to 
create and display session attributes) to build two WAR files: 
session1.war and session2.war.  The 'webapp' Ant target builds and 
deploys both the Tomcat-specific files as well as deploying the two 
webapps.  You will need to modify the build.properties file to point to 
your instance of Tomcat.

To test this I executed the following HTTP requests:
  * http://localhost:8080/session1/     -- index page
  * http://localhost:8080/session1/dataForm.jsp
Enter form fields: var1 and val1
  * http://localhost:8080/session1/dataForm.jsp?attrName=var1&attrValue=val1
This request returns to the form and displays the newly set session 
attributes.

Now go to the second webapp:
  * http://localhost:8080/session2/     -- index page of other webapps
  * http://localhost:8080/session2/dataForm.jsp
Enter form fields: var2 and val2
  * http://localhost:8080/session2/dataForm.jsp?attrName=var2&attrValue=val2
Now this page displays both session attributes (var1 from webapp1 and 
var2 from webapp2).

Attached is the catalina.out log file for this interaction.  BTW, I 
simply used System.out print statements rather than something like Log4J 
as I didn't want to tweak any additional Tomcat configuration or run 
scripts.

BTW, I tested this on JDK v1.5 and Tomcat v5.5.

I hope that this is useful to a few of you.  If you do take a look at 
the code and have some suggestions for improvement, please let me know.

Cheers,
Bryan
> Hello Tomcat users,
>
> I have a need that I believe Tomcat's pluggable session manager
> facility can satisfy, but I am having trouble getting it configured.
>
> BTW, I have googled and searched the mail archives on this topic
> and have not found anything useful yet.
>
> My application requires a modular architecture in which pluggable
> modules can be added a removed.  We would like to use the web
> container's ability to deploy, undeploy, and redeploy WAR files as
> a means to install, uninstall, and upgrade the modules within our
> system.  However, there is also a need to share session state between
> these modules which is not allowed in the servlet specification.
>
> I have researched a few solutions (such as using a Singleton in a
> common/lib/ package), but these solutions appear to require a non-
> trivial amount of infrastructure (and configuration of filters and/or
> session listeners) for every webapp.  I would like to avoid all of that
> explicit infrastructure and hide the complexity by using a custom
> session manager.
>
> Before I proceed with my question, does anyone have any other
> suggestions for solving the above problem?
>
> OK, here is the test case that I am trying.  I have created a very simple
> decorator which implements the org.apache.catalina.Manager interface.
> It simply delegates all calls to an instance of StandardManager and
> prints a message to System.out.  Attached is the Tomcat config file
> that I am trying to use to configure my custom session manager.  I am
> trying to use the <DefaultContext> tag to setup the manager on all
> webapps.
>
> Unfortunately, when I run a simple webapp (after restarting Tomcat, of
> course) I am not seeing any output in any log file (nor to the 
> console) from
> my test manager.
>
> Is my configuration invalid?  What am I missing?
>
> Sincere thanks,
> Bryan
-- 

*StillSecure*
Bryan Basham
Senior Software Engineer (UI Development)

F 303.381.3881
C 303.917.4546
www.stillsecure.com <http://www.stillsecure.com>
/The information transmitted is intended only for the person
to whom it is addressed and may contain confidential material.
Review or other use of this information by persons other than
the intended recipient is prohibited. If you've received
this in error, please contact the sender and delete
from any computer. /


Mime
View raw message