tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: Connector compatibility between TC 4.0 and 4.1
Date Fri, 21 Dec 2001 20:02:44 GMT
As appealing an idea as this sounds (packaging plug-in modules as
webapps), it doesn't solve the underlying issue -- different containers
have radically different internal architectures, and packaging the plug-in
as webapp doesn't avoid having to deal with that.  You still have to
bridge the architectural differences for "installing" the plug-in
functionality in the container, using container-specific APIs.

To be successful at bridging this gap, you've really only got a couple of

* Create an external common API for things that are not architecture
  dependent (like web connectors) that a container can choose to
  support or not support, and don't bother trying to standardize
  things that are radically different between architectures (for
  example, RequestInterceptor vs. Valve, or the very different
  concepts of how the core components of the container are organized).

* Create a meta-architecture (via a set of common APIs) that all
  containers must support -- never mind that it might mandate doing
  things in a totally different way than any existing container.

IMHO, the latter option is not practical.  Packaging plug-in functionality
as a web app does nothing to help resolve the basic issue that containers
are different on the inside.  And, if you went to the effort to do this,
you'd spend your time more efficiently by just creating a container
conforming to those APIs and be done with it.

Oh wait ... we've already done that ... twice :-).  That seems entirely
sufficient to me.


On Fri, 21 Dec 2001 wrote:

> Date: Fri, 21 Dec 2001 11:34:57 -0800 (PST)
> From:
> Reply-To: Tomcat Developers List <>
> To: Tomcat Developers List <>
> Subject: RE: Connector compatibility between TC 4.0 and 4.1
> 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.
> Costin
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message