On Fri, 4 May 2001, Craig R. McClanahan wrote:
> > +1 for separate repository, but I preffer
> >
> > "jakarta-tomcat-modules" or some common repository.
> >
> > Reason: connector and jasper are just particular modules that could be
> > used in multiple versions of tomcat ( like 3.2, 3.3, 4.0 or 4.1 ). There
> > are other pieces that could be developed in the common repository.
> >
>
> If you mean 'modules' in the general sense of a shareable component (so
> that it would include interceptors for 3.2 and valves for 4.0, for
> example), I don't care much about the name, although your particular
> choice doesn't avoid the political appearances issue. If you mean
> 'modules' as in something that implements the 3.3 apis for modules, be my
> guest -- but that makes it pretty useless to many. (3.3 apis are
> irrelevant to anything I'm interested in, for example.)
I mean modules in the sense of "pieces" of add-on functionality that are
not specific to a particular tomcat implementation.
For example the web-based build tool ( where I'm trying to create an easy
to use interface for the build process ), and is in no way specific to
a tomcat version ( except that it's using 2.2/1.1 ). Or a logger that
could be used in 3.2, 3.3 or 4.0.
> > If you want, we can have all 3 ( connectors, jasper, modules ) - but I
> > would really want a repository to replace the current /proposal and be
> > usable in multiple tomcat versions.
> >
> > For example the JAAS auth, the logger ( that would be really needed in
> > 3.2 for example ), and maybe even the build tool.
> >
>
> I've said it before, and i'll say it again -- 3.2 is in maintenance mode,
> and doesn't need any further focus for enhancements. Time spent providing
> enhancements there would be better spent focusing on its replacement.
Even if you mean 3.3, I don't agree :-)
The container itself is mostly done ( 3.2 and 3.3 ), but you need more
than a container for a production system.
Tomcat itself is just a small part of a solution. You also need to
integrate it and to add what is needed for a "real world" use.
And those modules are mostly independent to the specific details of tomcat
APIs. A good implementation should work for 3.2 ( as the current
production system ), and should work as well for 3.3 or 4.0 ( with
reasonably small adapters ).
Costin
