Re: Some JK2 ideas

[Jess Holle]

Mladen Turk wrote:
-----Original Message-----
From: Jess Holle
   

If you're proposing getting rid of JkUriSet, DON'T!
   

That's exactly what I whish to do.
 

It is *very* helpful to be able to mount URI's for a specific 
web app in an Apache .conf file that contains all the other 
settings for that web app.
   

I'm driving the Peugeot 406, and it would be very helpull that I can get a
spare part from 'Yugo' :)
So, will I adapt my Peugot, or just try to find a cheaper part?
Also as I stated the workers2.xml should be the main config, for _all_
platorms. No exceptions. Like there is no exceptions in Java itself. 
 

I can see eliminating all web-server-specific configuration options in 
the long-term -- though keeping the existing options around for a while 
as deprecated alternatives would be nice, i.e. to give everyone a 
conversion grace period.

I cannot, however, see pushing everything into a single XML file.  This 
is insufficiently modular for a web server that may have dozens of web 
apps with their own specific settings.  Rather what I'd suggest is 
something like:

   workers2.xml
       * contains all mod_jk2 settings that are not web-app specific
       * /can/ contain all mod_jk2 settings for the given server
   one or more directories containing web-app specific settings (again
   specified as XML)
       * each worker defined in workers2.xml could have its own
         sub-directory and each web app could thus be mounted by each
         placing an XML file containing any settings for it in the
         appropriate sub-directory
       * other alternatives are possible (e.g. each web-app's XML file
         could explicitly call out the worker instead and all the XML
         files could be in one location, though I like the
         mapping-by-placement arrangement)
This suggestion is essentially how Tomcat 5.0.x handles web-app 
<Context> elements -- down to my shameless pilfering of the 
mapping-by-placement idea.  It was painful to add <Context> elements 
directly to server.xml when this was required, i.e. when such modularity 
was not supported, the Tomcat group realized this and an easy to use 
modular configuration approach was provided.

I'd wholeheartedly support this sort of an approach (and would be 
grateful to have XML rather the current workers2.properties format).  
Killing off JkUriSet without such an improved modular alternative 
(especially without a grace period) would *not* be appreciated -- by me 
and a number of others I know who don't follow this list.  It would 
essentially push me towards sticking my customers with mod_jk indefinitely.

A final suggestion: A utility to produce the new XML file format from 
the old formats (not part of the mod_jk2 binary, of course) would be 
helpful.

--
Jess Holle