tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Jk2 object model
Date Thu, 08 Jan 2004 16:42:29 GMT
The major mistake in "jk2" is the "2" in the name. It was an error to
fork ( even if it was easier to code and move it ) instead of improving 
mod_jk and adding/fixing.

In JNI mode and from configuration perspective - as well as ability to 
use non-tcp-socket communation - jk2 is way ahead. As code organization
and readability - besides the "original" OO model - jk2 is better.

But it works as well as jk, and just like jk it works "well enough" - so
I agree that at the moment they are "dead" from the point of the active
development. I have a feeling even tomcat is getting close to this 
point, I can hardly find any major "itch" in tc5.

We should probably use the term "stable and done" instead of "dead" :-)

Regarding "ease of use" and fancy protocols - all this requires an 
object model. I agree that the current OO is not perfect, but it works
without the dependencies other OO models would have ( XPCOM -> NSPR ->
remember the fun in licence dicussions ).

So I think the first question would be what to do about the object 
model, keep/improve the current one or switch to a (XP)COM-like ( or 
C++, or Gtk+ or OpenOffice ).

After we have objects with JMX-like behavior, configuration and 
extension in any direction can follow the same model as tomcat.

Should we call this jk+ or jk3 ? IMO it would be a major mistake, even
bigger than for jk2. We have far fewer "itches" and less time, and a 
fork allways requires much bigger effort in addoption. The main reason 
people don't use jk2 is that jk1 works well enough for the task, plus 
different config. Same would happen to a jk3 - whenver this would be ready.

So my suggestion ( deja vue ? ) is to use "evolution" :-). A change in
the OO model ( if needed ) or fixing/improving the current one is not
as big change as it seems - it's mostly in initialization code.

Javaspaces, other protocols, other transports and other servers can be 
added at any time - but I think it would be vital to _add_ them to an
existing base instead of adding yet another new connector.


Mladen Turk wrote:
> Hate to quote myself, but...
>>As I said, the performance isn't a priority here, but rather 
>>I'm sure that TC guys will be open here, and we will see 
>>(perhaps even in
>>5.1) the 'open TC API', that could be directly used, or 
>>seamlessly integrated from the native side.
>>I would prefer to see that, rather then trying to 'discover' 
>>something, and after all it would 'stay in the house', since 
>>I wish to make a
>>connector(integrator) for Tomcat, not for some xyz container.
>>Of course this would imply the firm collaboration with the TC 
>>guys, but once again I don't wish to pack/unpack something 
>>over and over again (I have JK for that).
> The concept (approach) as I see it is to be able to make a connector
> (integrator), that would allow the zero-based-configuration. Meaning that
> loading a module (filter) will automatically map the Tomcat web space to the
> web server.
> No matter if the TC was started in or out of the process, and no matter how
> much clustered instances exists on different nodes.
> If there is developer interest for that, I'm willing to 'shake the things'.
> MT.

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

View raw message