Kief Morris wrote:
> 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.
>
Well, StandardManager already supports saving and restoring sessions across
restarts -- it just doesn't do the event notifications right.
>
> (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
> >classes.
>
> +1 - I can do this also.
>
I've actually got a commit ready to go on all of these, plus an extended unit
test to prove that it fires all the right events at the right time. I'll go
ahead and check it in.
>
> What do you think about pushing more functionality up into ManagerBase,
Either that, or subclass StandardManager instead if it makes life easier.
>
> and creating a SessionBase class?
Sounds good as well.
> Most of what I want to do shouldn't
> need subclassing of StandardManager/Session.
>
Some of the places where we're casting to StandardSession seem to imply that
these methods should really be in the Session interface itself. I was
particularly thinking about the new activate() and passivate() methods, which
every session implementation should be ready to implement. There are
probably others as well.
>
> Kief
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
