tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Anderson" <mmand...@novell.com>
Subject RE: Jk2 object model
Date Thu, 08 Jan 2004 21:15:31 GMT
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
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


Mime
View raw message