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. 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]
