tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Some JK2 ideas
Date Wed, 14 Jul 2004 17:36:11 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message