tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5
Date Wed, 04 Dec 2002 21:42:16 GMT
Jeanfrancois Arcand wrote:

>>>>> This is hard to do (Catalina has never been written to allow facades).
>>>>> Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.

> Euh...I also like the module idea, but I share Remy's view and I doubt
> about having a single o.a.c workspace for all Servlet specs (starting
> 2.3 & 2.4). Without facade, I don't see how we can achieve that. I would
> prefer having a shared workspace for everything except stuffs related to
> Servlet. Something like:
> 
> o.a.catalina (basic web server stuff)
> o.a.catalina.servletEngine (where the Servlet spec is implemented)

Well, if you move auth* and session to modules and use Action ( or something 
like that ) for hooks - catalina will be the facade and have all the 
Servlet spec implementation.

And all modules should work with any version of tomcat that uses coyote
( i.e. 3.3, 4.0, 4.1, 5.0, etc ). 

If we also move ( or replace ) some of the 3.3 modules ( for example
the mapper, or auth* ) - then 3.3 core will also act as a facade. 

There is no need for a servletEngine package, it's much better to go 
the other way around and move ahead with moving modules out.

We'll need to keep the existing modules in - probably as small wrappers
around the new modules - for backward compatibility. So only new 
modules or existing module implementation will need to move ( and not
all at once ). Probably a "backward-compat" module could be used
for all the code that is deprecated but needs to be around for backward
compat.


> or something like that. That probably what Facade means....Maybe I'm
> dreaming ;-). We should really think of having an extension mechanism
> where module can be added easily. The solution resides probably by
> having a consistent hook mechanism...

Part of the solution, yes. The other part is ( IMO ) JNDI/JMX.

JNDI+JMX will take care of configuring ( you can't do it with JMX alone -
you also need JNDI to locate the objects ). A "module" will be an mbean
that also implements the hook interface.

We can theoretically use JMX alone - without a hook interface and using
invoke() - but that would hurt performance. 

To add a module - you can use any JMX mechanism ( including mlet ) 
_and_ register the module in a catalina:/jmx/OBJECT_NAME jndi.
Tomcat will listen for object notifications - and pick up all
modules and configure them based on the name.

The JNDI/JMX name of each module is very important - as it contains
the position where it must be inserted.

It is quite simple. And it can be implemented without affecting too
much the existing code - it'll be just another module. We'll need to
add some JMX awareness into the code, but it seems the proposal
to require jmx will pass.


Costin






--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message