tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Some JK2 ideas v.2
Date Mon, 19 Jul 2004 16:01:22 GMT
Henri Gomez wrote:

> Costin Manolache wrote:
>> Mladen Turk wrote:
>>> Hi,
>>> All (except Costin) developers has to say something, so my conclusion is
>>> that we are not dead after all ;)
>> I'm alive as well, and I have something to say - I spent last few 
>> weekends playing with coyote and tomcat, probably in few weeks I'll 
>> have something working and I'll get back.
>>> Seems that the major obstacle is the configuration, so I propose that we
>>> forget that for a while, and make a
>>> 'generalized' environment that will sattisfy all the 'needs'.
>>> That environment could be called APR_JAVA and it will be resposible for
>>> os->java communication, having AJPXX, and 'JNI' as one of the possible
>>> protocol stacks.
>>> It will have a generic mapping mechanism (pcre enabled) for 
>>> registering URI
>>> mapings, setting communication properties, so that one could make a 
>>> suport
>>> from any container (webserver).
>> URI mapping is already duplicated in the web server and catalina, 
>> please not a third mapper :-)
> Of course, and we could start with a simple mapper using Location/EnvVar.

If we don't use Location - then even if httpd.conf is used, it'll still 
be a different config file, just it'll be inside httpd.conf :-).

Location is what allows it to play with other apache modules and look 
natural to apache admins.

>>> It will abstract the container<->java communication to the level of
>>> 'directory and file' so that one can open a connection to TC like 
>>> opening a
>>> file, or simply speaking a 'Virtual File System', so that one can either
>>> 'mount' a volume like '/servlets' or a file filter like '*.jsp'
>> Depends on what you want :-). Request forwarding from server and 
>> tomcat works reasonably well, it's the other stuff that is hard, and 
>> it doesn't map so well to "VFS" model ( auth, conf, etc ).
> Request forwarding is still the main feature, but we'd like to some 
> dynamic topology (webapp discovery, cluster state updates...)


Request forwarding is quite simple - and well understood. The other kind 
of communication is the problem. Again, since most of it is off-line ( 
not in critical path ), a simplified get/set/event model ( JMX-like :-) 
might be a good choice ( instead of a special packet type for each use 
case - webapp discovery, cluster, etc ).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message