tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Connector compatibility between TC 4.0 and 4.1
Date Fri, 21 Dec 2001 19:34:57 GMT
On Fri, 21 Dec 2001, Kevin Seguin wrote:

> > My thinking ( for 4.1/3.3 ) was to have j-t-c built as a
> > 'standalone module', a trusted/priviledged webapp that can be
> > deployed and
> > is self-contained.
> >
> can you provide some more detail?  i'm quite interested in learning more.

It's quite simple - the idea is to 'package' tomcat modules ( i.e.
anything providing additional functionality ) as 'plain' WAR files.

Why ? Many good reasons:

- reuse - all the infrastructure for webapps will apply to modules as
well. With a bit of work we can get dynamic module loading/reloading,
deployment ( including 'hot' ) etc. Even setting module properties will
benefit from the UI for web.xml admin ( i.e. most config can be done
using Context attributes in web.xml ).

- self-contained and well defined environment for modules. We'll know
that the directory structure on deployment will be clear, we can call
getRealPath(/) and know where all our files are located. That's container
independent, etc.
( I assume modules will be 'expanded' - that's a requirement, as we'll
use the directory structure to generate configs, etc)

- a lot of the module can be implemented as plain servlet/jsp. Like
'seeing' jk status, logs, etc. Again, everything is self-contained and
have a defined structure ( like in a webapp )

- the original reason for doing that ( in 3.3 ) was simplifying the code.
We wanted 3.3 to be as simple as possible, with a minimal core providing
the 'referenece implementation' part and nothing else, and have all the
'features' implemented as optional modules. That's what the 'modules/'
directory is for. 3.3 does have all the features from 3.2.x, but we tried
to not add anything else - any feature should be provided as a module.

- of course, the build environment and everything else becomes more
'faimiliar' for people. It's a webapp that happens to implement and use
one extra API ( or few APIs ) to interface with the container.
It's no different from a webapp that is using diferent parsers or
databases. The only 'special' thing is that our webapp can affect the
container behavior ( exacly like /admin or /manager ).

The only problem is making the 'webapp' usable on multiple containers (
that support the concept ). This is quite painfull for 4.x ( including 4.1
), because in order to access the internals you need to implement an
interface on a servlet ( and that will not load in 3.3 ). But I think
there are some ( maybe ugly ) ways to get around this.

Again, in a webapp that does database access or xml you want to be able to
support multiple 'drivers' - a module doing authentication will also have
'drivers' for different servlet containers, same for jk.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message