Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <40F59BFF.9060509@ptc.com>
Date: Wed, 14 Jul 2004 15:47:59 -0500
From: Jess Holle <jessh@ptc.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.7) Gecko/20040616
MIME-Version: 1.0
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
Subject: Re: Some JK2 ideas
References: <200407142009.i6EK9Hhb027980@pop.xnet.hr>
In-Reply-To: <200407142009.i6EK9Hhb027980@pop.xnet.hr>
Content-Type: multipart/alternative;
 boundary="------------010508000106070603080603"

--------------010508000106070603080603
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Mladen Turk wrote:

> 
>
>  
>
>>-----Original Message-----
>>From: Jess Holle
>>    
>>
>>>Who ever asked the poor apache admin  about the TC's config ater all?
>>> 
>>>
>>>      
>>>
>>It really does not matter who the admin is.  Even a 
>>sophisticated admin is going to want to have file 
>>modification dates they can trust on various aspects of the 
>>configuration so they can answer "did I change this part?" questions.
>>    
>>
>Don't think that the current config provides that either. 
>  
>
It does if you use JkUriSet.  I have a separate (auto-generated) .conf 
file for every web app containing mod_jk, jk2, etc, etc, configuration 
and another auto-generated .conf file for each web app (included by the 
first) containing any/all Apache-side authentication configuration for 
the web app.

I can have (and auto-generate) more files per web app, but I (and others 
I know) won't move to anything that regresses from this level of modularity.

>>Using a modular multi-XML-file approach does not pollute the 
>>result with any additional server-specific or Tomcat-specific 
>>baggage.  It just makes management and automated 
>>configuration/installation much more workable.
>>    
>>
>In contrary, it makes it simpler, cause you have a common denominator, and
>that is 'well documented' config file, usable on any container.
>  
>
What I'm saying here is that I want modular per-web-app config-file 
support.  I don't care if any/all server-specific and Tomcat-specific 
stuff is removed from them -- actually that is laudable in the long term 
even if a bit painful in the short term.  I just don't want to be forced 
into shoving the whole configuration into a single file (or using XML 
entity reference hacks which are beyond ugly -- and require the main 
file to be modified to add extra entity references which is highly 
undesirable).

>JkUriSet can be used only on the Apache server.
>So, the question is, are we adapting the apache module to other servers, or
>we have a
>container independent module.
>  
>
I think you are missing my point:

    Go ahead and remove JkUriSet, just add equivalent functionality to
    do per-web-app configuration files.  Just do it in a
    server-independent, XML-based way this time around.

>If you wish to have a few virtual hosts, you will need to apply two
>completely different
>configurations for each side anyhow (httpd.conf or click-clik and
>server.xml).
>Having specific directives for each container makes that even more
>complicated thought.
>  
>
I'm just looking for things like:

    * Web app X:
          o jk-mount /x/*, /y/*, and *.jsp
          o map these all to worker X
    * Web app Y
          o jk-mount /m/* and *.jsp
          o map these all to worker Y

    ....and so on....

With the information above (and any other things which are justifiably 
per-web-app *and* per-web-app support already exists for) be specifiable 
in separate files, one for Web app X, one for Web app Y, and so on.

--
Jess Holle


--------------010508000106070603080603--