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...)
+1
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 ).
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
