TC3.3: Few proposals ( IMPORTANT )

[Costin Manolache <cm...@yahoo.com>]

Hi,

I think all the changes required to support multiple
facades are done ( at least enough to get Servlet 2.3
implemented ).  In order to do that some code
reorganization was needed, and I tried to keep this
limitted to a minimum.

On the other side I think the benefits of doing this
code modularization are already visible and it's worth
making few more steps.

The idea comes from Netbeans and their code organization.
We already have this organization for the J2EE integration
code ( in src/j2ee) and now for the 2 facades ( src/facade22, 23).

Each module will have a clear set of dependencies, and
( with the new "java -jar tomcat.jar" ) it may be possible
to do all kind of tricks: detect changes in core libs and
do hot-upgrade ( without restart ), upgrades, etc.

The proposal is:

1. Create a src/util module for tomcat_utils.jar.
It will have no deps on external code, and will contain
all the reusable util code we have.

2. Move logger from org.apache.tomcat.logger to
org.apache.tomcat.util.log.  ( even if IBM logger will
be used, the code may still be usefull)

3. reorganize utils ( move thread pooling to
util.threads, enumeration, queue, hashtables to
util.collections,

4. Move tomcat.context, tomcat.request, tomcat.service.http,
tomcat.service.connector into tomcat.modules. ( that can
be delayed until the hook registration will be re-designed)

5. Create top-level ( src/xxx ) codebases for non-core
functionality. For example the JNI & AJP connectors
can sit in a src/adapters ( and 100% java builds can
be done), all extensions ( like autoconf, etc) will sit
in src/extra ( and builds containing only the minimal servlet
implementation can be done ).

Impact:
- the code will be the same - so no functionality will be
affected.

- the build process will have to change, but it have to
change anyway to support 2.3 facades.

- this will improve colaboration between developers,
and reduce conflicts. It would be also possible ( if
anyone steps in ) to have contact a  person for
each module.

- Reusablity: the util can grow in a collection of
general-purpose utilities. I am still planing to
add some utils from xerces and more generic tools
( startup, command line option processing, etc).

- maintanance will improve

- the most important ( for me) - the separation
between modules will be cleaner and we'll avoid
complex code ( like tomcat 3.0 :-)
Take a look at xerces1 ( I spent few day attempting
to build xerces without schema - I still can't.
Schema contribute 1/2 of the 1.4 M of xerces.jar).

- the only change in code that depends on tomcat
will be import lines.

Costin

Re: TC3.3: Few proposals ( IMPORTANT )

[Christopher Elkins <ce...@scardini.com>]

> 1. Create a src/util module for tomcat_utils.jar.
> It will have no deps on external code, and will contain
> all the reusable util code we have.
>
<snip>

I recall seeing a recommendation by someone once upon a time to create a
separate module for this purpose, something like jakarta-utils. There's a bunch
of code in JServ and Turbine that could find a home there as well, and it'd be
nice if it were all external to Tomcat if it truly is reusable across projects.

>
> Costin
>

--
Christopher Elkins