> > 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.
> >
>
> Is 3.3 ready to give up on JDK 1.1 compatibility? If not, the extra effort to
> maintain it is not particularly "productive" from a Tomcat 4 point of view.
That's a very common misconceptions about JDK1.1 compatibility - it
doesn't imply in any way that tomcat3.3 can't use JDK1.2 features.
Tomcat 3.3 is using a number of 1.2 features ( context class loader,
doPriviledged, URLClassLoader, etc ) - the _core_ and the _required_
modules are strictly JDK1.1.
In other words:
- tomcat3.3 compiles with JDK1.1 ( since all modules depending on 1.2 are
compiled only if 1.2 is detected. Same for JSSE ).
- tomcat3.3 should run fine with JDK1.1 and work as a normal servlet
container
- it doesn't have to provide all the functionality that would be available
in JDK1.2 - for example it'll not be capable of sandboxing or set the
context class loader or URLClassLoader.
Advanced session management is just a module ( and BTW, I wouldn't vote
for including it in tomcat3.3 in any way) that can be used as an add-on.
It doesn't affect the default session manager ( which is JDK1.1
compatible).
Also, a small note regarding the code organization and reusability.
Of course, the session manager needs to send the right events and read
data from the server. But that can be easily abstracted and most
functionality made re-usable.
Many people talk about OO and reusing - but the reality is that very
little happens, and the main reason ( IMHO ) is that in many cases a lot
of dependencies exists. The end result of this can be tomcat3.0.
( for example the session manager can use a Bean-style API, with
Listerners for all generated events and setters for all the properties it
needs. Instead of pulling data from the container, an adapter can push
the needed data and generate the right servlet events using the session
manager listeners.
IMHO it would be a mistake to write a session manager using the same
abstractions as in a servlet container - after all the task is to store
data and the requirements are pretty specific )
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
