Return-Path: 
 <users-return-191259-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 63072 invoked from network); 6 Feb 2009 10:40:26 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 6 Feb 2009 10:40:26 -0000
Received: (qmail 27657 invoked by uid 500); 6 Feb 2009 10:40:11 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 27469 invoked by uid 500); 6 Feb 2009 10:40:10 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 27458 invoked by uid 99); 6 Feb 2009 10:40:10 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Feb 2009 02:40:10 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.174 as permitted sender)
Received: from [212.85.38.174] (HELO popeye.combios.es) (212.85.38.174)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Feb 2009 10:40:02 +0000
Received: from [192.168.245.129] (p549EA708.dip0.t-ipconnect.de
 [84.158.167.8])
	(authenticated bits=0)
	by popeye.combios.es (8.13.8/8.13.8/Debian-3) with ESMTP id n169jfJY011444
	for <users@tomcat.apache.org>; Fri, 6 Feb 2009 10:46:41 +0100
Message-ID: <498C05BF.9020508@ice-sa.com>
Date: Fri, 06 Feb 2009 10:41:19 +0100
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: WEB-INF/classes vs WEB-INF/lib/classes.jar file
References: <BLU145-W4482E2DB3F2697C2CF7C5DC3C00@phx.gbl>
 <gmeccs$s48$1@ger.gmane.org> <498AC712.2060403@ice-sa.com>
 <498ACFCB.5060004@ceti.pl> <498AD66A.4080601@ice-sa.com>
 <gmgbcu$isv$1@ger.gmane.org>
In-Reply-To: <gmgbcu$isv$1@ger.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV 0.92.1/8957/Thu Feb  5 18:31:01 2009 on
 popeye.combios.es
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

Bill Barker wrote:
> "Andr� Warnier" <aw@ice-sa.com> wrote in message 
> news:498AD66A.4080601@ice-sa.com...
>> Mikolaj Rydzewski wrote:
>>> Andr� Warnier wrote:
>>>> if I have a webapp consistig of just a couple of classes and a 
>>>> WEB-INF/web.xml config file, but this web.xml file contains some 
>>>> parameters that are "each-client-dependent", and some customers are 
>>>> insisting to receive the updates as a war file, how can I achieve that ?
>>>>
>>>> Someone earlier here mentioned that you could put the settings in a file 
>>>> outside the application, but that is not possible in this case, or is it 
>>>> ?
>>> You can have web.xml parameter, e.g.
>>>
>>> <context-param>
>>>    <param-name>config-file-location</param-name>
>>>    <param-value>/filesystem/path or URL or 
>>> some-other-location</param-value>
>>> </context-param>
>>>
>>> And then you can retrieve parameter value, thus, read config file.
>>> Idea is, that param-value is the same for every client/build. E.g. points 
>>> to configuration file in $CATALINA_HOME/conf. So you can have one war 
>>> file and client dependant configurations.
>>>
>>>
>> Ok, that would work if you wrote the webapp yourself, and all the filters 
>> that go with it.  It would however not work if there are some 
>> customer-specific parameters in web.xml, that are outside of your control. 
>> (I'm thinking for example of a UrlRewrite or jCIFS filter)
>>
>> Would there be a way to create a war file that does not contain a 
>> WEB-INF/web.xml file, but maybe contains a "soft link" to a whole web.xml 
>> file located somewhere else ?
>>
>> The basic idea is : I could still give my customer a war-file that he can 
>> deploy containing my updated classes of jars or whatever, but it would not 
>> overwrite his customer-specific web.xml when he deploys it.
>>
>> I think this issue is so general/generic that there must exist some way, 
>> no ?
> 
> This is totally Tomcat specific, so won't necessarily port if you decide to 
> change containers (but without looking probably still works for GlassFish 
> and JBoss).  Tomcat does Ant style variable replacement when parsing web.xml 
> (both the one in conf and the one in WEB-INF).  So something like
> 
>  <context-param>
>     <param-name>config-file-location</param-name>
>     <param-value>${my.config.file.location}</param-value>
>  </context-param>
> 
> will work if the System property my.config.file.location is set by the 
> startup script/Windows service manager.
> 
That sounds like a good idea !
Usually, there are only a few parameters that change per customer, like 
the IP address of some external server, or some login id/pw for a remote 
service.  That would really do the trick in most cases.
In addition, it would avoid having to put some potentially sensible 
values in a web-xml file which has to be readable by the Tomcat user.

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