I agree that the current connectors (jk and jk2) are fairly "stable and done" because they just work. The hardest part in using them is that there is a lot of duplicated setup between the Java/Tomcat side and the webserver configuration just to get things working. Then, when you add a new webapp into Tomcat, you have to remember to update the webserver configuration to handle the application. I like what Mladen said here:
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.
Can we do this by evolving mod_jk or mod_jk2? I don't know. I believe it is possible and agree with Costin that this is probably the better way to go because this is what our users recognize as the "connector of choice". Look at what happened with mod_webapp. I think that Pier and and Jean-Frederic did some great work on this, but the community (developers and users) never really got behind it.
The mean problem was using an instable APR API.
Another difference between mod_webapp and mod_jk/mod_jk2 was the thinking to have a Servlet Engine as an extention of Apache not a connector between Tomcat and Apache.
The other good thing of mod_webapp is to have a good protocol (WARP). May be we can reuse it in the new connector.
BTW: I am using mod_jk2.
I don't know if that is because it was "too revolutionary" or what. I'm just worried that if we break too far from jk, we'll end up going nowhere.
If we can evolve mod_jk or mod_jk2 to allow "zero-based-configuration" as Mladen suggests, I think that is the path that we should follow. If we have to revolt :-) and re-architect, we need to make sure that what we produce is soooooo much better that people can't wait to get it and help plug it into their web server. This includes getting it running and working on as many OS platforms and webservers as possible right up front.
If there is developer interest for that, I'm willing to 'shake the
things'.
I'm (finally :-) ready to start diving in and help shake things up. <aside>
I got stuck doing the management thing for a couple of years so I
couldn't (didn't :-( ) contribute as much but I'm back on this pretty
much full time now - as an engineer, not a manager :-).
</aside>
Mike Anderson Sr. Software Engineer [EMAIL PROTECTED] Novell, Inc., The leading provider of Net business solutions http://www.novell.com
[EMAIL PROTECTED] 1/8/2004 10:16:03 AM >>>
From: Costin Manolache
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.
How about 'revolution'? On the other hand how does the evolution differs from revolution?
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.
I hate the word connector.
I would like to name that new thing integrator (jakarta-tomcat-integrator, how that sounds?) It would IMO better describe that new approach (at least the one I have on my mind).
and...
If we don't put ourselfs out from 'reusable' concept, nothing new will
ever
be done thought. Trying to reclyle something, as you nicely said "stable and done", is
poinntless from the '(r)evolution' perspective.
Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else.
MT.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
