Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5

[Costin Manolache]

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 meansMaybe 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:   
For additional commands, e-mail: 

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5

[Costin Manolache]

Glenn Nielsen wrote:

> Remy Maucherat wrote:
>> Glenn Nielsen wrote:
>> 
>>> With Tomcat 4.1 released many tomcat developers have been reticent to
>>> add new features
>>> to its codebase for a number of reasons.  All the development going on
>>> in Tomcat 5 and
>>> wanting to keep the number of codebase's where bug fix patches have to
>>> be applied to a
>>> minimum.
>>>
>>> There are alot of ideas for new features that I would like to see end
>>> up in a Tomcat 4.2
>>> release. Especially since we don't know when the Servlet 2.4/JSP 2.0
>>> specs will be finalized
>>> so that Tomcat 5 can be released.
>>>
>>> There isn't that much difference in the core of catalina between the
>>> Servlet 2.3 and
>>> Servlet 2.4 specs. It might be possible to change the
>>> jakarta-tomcat-catalina codebase
>>> to make it neutral to what Servlet spec is implemented.  Then this
>>> codebase could be
>>> used for future Tomcat 4 and Tomcat 5 development.  And we then have a
>>> common codebase
>>> for applying bug fix patches.
>>>
>>> This seems to fit in with the direction we have been going where
>>> different components
>>> are kept in different code bases. naming, connectors, jasper, etc.
>>>
>>> Comments?
>> 
>> 
>> 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.
> 
> 
> Right, I am aware of that. There isn't that much difference between
> Servlet 2.3
> and Servlet 2.4.  Having a common codebase for both would make addition of
> new non spec related features easier and bug fix patching easier.

There are new methods in interfaces, etc. It won't be easy, I tried that 
( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping,
security - and we already have connectors and Request.

That will also simplify the codebase in j-t-catalina - i.e. the code will
be more focused on implementing the servlet spec.

> There needs to be someplace where new features can be added to the Tocmat
> 4 branch. You have been against adding new features to Tomcat 4 head,
> creating a Tocmat 4.2 branch for developement, and now against making
> j-t-catalina common to both Tomcat 4 & 5.

I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 people 
to vote +1 on 4.2 ( i.e. who are interested in working on it ), then
I don't see any reason not to do it. 

I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers.
I voted -0, I think Remy will change the vote to -0 as well. 
My -0 means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.



> If this is what you want then perhaps you should propose a VOTE to freeze
> all work on
> Tomcat 4 except for bug fixes.  And I mean all work.  If the community
> votes to do that then I will stop asking and perhaps go review the rules
> for revolutionaries.

I don't see the point of a vote to freeze ( and I think it would be a very 
bad idea ). 

Tomcat4 ( and tomcat33 - I think ) can get new features if enough interest
exists. They do get new features all the time ( at connector level ). 
If any of the features in 5.0 gets 3 +1 for porting it back to 4.x - 
then it should be done. 

If we move auth* and other stuff to couyte level and use Action - more 
featurs will be common across versions.

You can start a revolution and make any changes you want in proposal/, but
you'll still need at least 3 +1 votes to release it (well, you need a 
majority - but again I don't see why anyone would vote -1 ).


Costin 








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