> >( +2 if he also ports them to tomcat 3.3 or makes them independent of
> >the container architecture - i.e. general purpose utils for
> >serialization/deserialization with a simple adapter for each server :-)
>
> Sure, the 3.3 code could be modified to use the Store interfaces to serialize
> its sessions, although that would require sharing the Session interface. Maybe
> a bit too much work for the current release cycle.
This doesn't have to be part of tomcat3.3 release - it can be a standalone
module. The only issue is that the code you write ( Store, impls, etc )
need to be "standalone" - i.e. be usable in any container.
( the session manager for tomcat3.2 is based on early catalina session
managers, but it was a huge pain to extract the session management and use
it, since it depended on a lot of internals - Request, Lifecycle, etc).
With the same functionality, you can organize the code in many ways. If
you look at tomcat.util you'll find that none of the tools there depends
in any way on any tomcat internal object. If the store can be written as
a general-purpose utility, and you keep container-dependent code in a
small adapter then more people will be able to use it or contribute to it.
--
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
