tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: How to configure a web app
Date Thu, 10 Jun 2010 15:43:34 GMT
Mark H. Wood wrote:
> On Wed, Jun 09, 2010 at 05:20:22PM +0200, Thomas Kloeber wrote:
>> Mark H. Wood wrote on 09.06.2010 17:03:
>>> On Wed, Jun 09, 2010 at 04:19:17PM +0200, Thomas Kloeber wrote:
>>>    
>>>> the problems I have are:
>>>>
>>>>      * the IP address of the backing database is one of the parameters
>>>>        that needs to be configured (in context.xml), so I can't get any
>>>>        data from the db unless it is configured...
>>>>      * the other confgurables (SPNEGO and kerberos stuff)  are in web.xml
>>>>        and as long as they are not set up correct, my app won't start!
>>>>      * sounds like a catch 22 to me ...
>>>>      
>>> Context parameter pointing to a properties file somewhere?  Then you
>>> can put the settings wherever you want them, and move them anytime
>>> with minimal fuss.  Install the app. outside of any appBase and use an
>>> external Context file ($CATALINA_BASE/conf/Catalina/<hostname>/<contextname>.xml)
>>>   to point to it and provide the parameter's value:
>>>
>>>    <Context docBase='/some/where/myapp'>
>>>      <Parameter name='configuration'
>>>                 value='/some/where/else/myapp.properties'
>>>                 description='where the configurables are'/>
>>>    </Context>
>>>
>>> You could just define the configurables as separate Parameters, but I
>>> would keep them separated from configuration of the servlet container
>>> (which the above is) if possible.  Tastes vary.
>>>    
>> sounds like a good idea, but what about the web.xml stuff? Can I use 
>> some redirection there as well?
> 
> I guess I don't understand why web.xml must be customized at all.
> In Tomcat, <Resource>s can be configured in a <Context>; <Environment>
> entries can be made in a <Context>; initialization parameters can
> be set in a <Context>.  Is there something else?  And Tomcat allows
> you to place the <Context> declaration outside of the app. as noted above.
> 
>> Caldarale, Charles R wrote on 09.06.2010 17:04:
>>>> how do you "make changes in context.xml inside archive"?
>>>>      
>>> Unpack it with the jar utility, update, repack.  Alternatively, you can supply
the<Context>  element in a separate file, and have the admin put that in conf/Catalina/[host]/[appName].xml
after modifying the site-specific attributes.
>> I was afraid you say something like that, but to me that is why to 
>> complicated/error prone...
> 
> I agree.  This always feels to me like telling someone that he can
> configure his word processor by using a binary editor on the
> executable.  Customers should never have to put their fingers inside
> the app; it should get customer-specific information from some place
> whose location is told to it at startup.
> 

Let me speak for the OP, and for others like me who do not necessarily 
write the applications and filters which they are installing on customer 
systems.
Sometimes, you have to deal with such third-party modules, which have to 
be used e.g. as a servlet filter in conjunction with your own 
application.  And sometimes, these third-party modules are like they are 
and you cannot change their code.  And sometimes, they require some 
site-specific parameters, which they expect to be in their respective 
<filter> section inside the application's web.xml file.
A typical example in my case is authentication servlet filters, which 
require for example a domain name or a domain controller address which 
is specific to each given customer.
If at the same time you have a customer who insists on receiving war 
files for application updates, you're cooked, because you have to build 
a customer-specific war file every time.

One suggestion I have in the case of Tomcat - and unfortunately only in 
the case of Tomcat - would be an extension mechanism to the web.xml 
file, which would allow some form of "include" in the web.xml.
(And maybe this would not be an extension, nor a Tomcat-specific thing, 
if XML per se already allowed such things).
Then one could insert in web.xml something like this :
...
<filter>
     <filter-name>NtlmHttpFilter</filter-name>
     <filter-class>jcifs.http.NtlmHttpFilter</filter-class>

   <!-- %%include-fragment: /some/path/local/to/customer/localparams.xml 
%% -->

...
</filter>
...

and in localparams.xml one would have e.g. :

<fragment>
     <init-param>
         <param-name>jcifs.smb.client.domain</param-name>
         <param-value>EU</param-value>
     </init-param>
</fragment>

(The above example being from some obsolete and no longer recommendable 
piece of software).

Is something like that possible ?

Because then, you could set up the localparams.xml file once for a given 
customer (and it would even be easy for them to edit it if needed), and 
supply them in the future with updated war files which would always be 
indentical for all customers, and this without having to modify the 
third-party filter code (which is not necessarily open-source).


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message