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.
Costin
Mladen Turk wrote:
Hate to quote myself, but...
As I said, the performance isn't a priority here, but rather usability.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
