tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: Jk2 object model
Date Fri, 09 Jan 2004 07:35:17 GMT
Mike Anderson wrote:
> 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
> mmanders@novell.com
> Novell, Inc., The leading provider of Net business solutions
> http://www.novell.com
> 
> 
>>>>mturk@apache.org 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: tomcat-dev-unsubscribe@jakarta.apache.org 
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message