tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kief Morris <>
Subject Re: [Tomcat 4] Session Handling Enhancements
Date Tue, 06 Feb 2001 10:02:00 GMT
Craig R. McClanahan typed the following on 04:40 PM 2/5/2001 -0800
>(1) Session Save/Restore Across App Restarts
>Currently, StandardManager saves and restores sessions across app
>restarts (i.e. autoreload if turned on, or normal shutdown and
>startup).  It should be modified to use the new passivate() and
>activate() methods of the session implementation to warn interested
>session attributes that this activity is taking place.

-0 How about stripping this entirely out of StandardManager? People who
want to keep sessions over restarts can use PersistentManager, leaving
StandardManager as a slimmer, simpler default.

(2) Modify StandardSession.readObject() and writeObject()
>Currently, when the session is being serialized, the attributes are
>removed via removeAttribute() -- which triggers calls to valueUnbound()
>of attributes that implement HttpSessionBindingListener, among other
>things.  Likewise, when the session is reloaded in readObject,
>setAttribute() is called and triggers calls to valueBound().  These
>calls were initially made to give session attributes some knowledge that
>a restart was being done.
>Now that the activate and passivate mechanisms are in place, I propose
>that these mechanisms be changed to *not* unbind and bind the attributes
>during these processes.  Any interested attribute can implement
>HttpSessionAttributeListener instead.

You mean HttpSessionActivationListener? If so I'm +1 on this - I can make
this change.

>(3) Change "final" classes
>One of the challenges Kief ran into is that StandardManager and
>StandardSession are both marked final, and therefore cannot be
>subclassed.  I propose to remove the "final" modifier so that this
>restriction is no longer in place.  Additional refactoring can be
>performed separately, but you should at least be able to subclass these

+1 - I can do this also. 

What do you think about pushing more functionality up into ManagerBase,
and creating a SessionBase class? Most of what I want to do shouldn't
need subclassing of StandardManager/Session.


View raw message