You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jason Cipriani <ja...@gmail.com> on 2008/10/30 11:23:17 UTC
Convenient web application configuration.
I'm using Tomcat 6.0.18 on Windows XP SP3, Windows Server 2003, and
Windows Vista (UAC disabled).
I have a web application with a lot of configuration options, all
currently stored as servlet initialization parameters in
WEB-INF/web.xml. The parameters are site specific and are different
for my development machine, the machines of the two other developers
working on the project, and the production machine. I am the only
developer working on the web application.
My problem is that web.xml is part of the web application WAR file.
Also web.xml differs for the 4 different machine the web application
runs on. This means that every single time I make a release, I have to
comment and uncomment blocks of parameters in web.xml, build 4
separate WAR files customized for each machine, and make the 4
separate WAR files available to each of the 4 people running the web
application. This is very cumbersome and it seems unreasonably
complicated, and has already led to a number of distribution mistakes
on multiple occasions. Is there a better place I can store
site-specific configuration options? Any suggestions would be helpful.
Similarly, I have a JDBC data source defined in META-INF/context.xml.
The data source parameters are different for each machine. Is there
some other way I can define data sources so that I don't have to
maintain separate WAR files for each configuration?
Ideally I'd be able to put the settings in context.xml and web.xml
somewhere outside of the web application directory, and leave them out
of the web-app's local files, and so they wouldn't have to be packaged
with the WAR and deploying the WAR wouldn't blow away existing
configuration data.
Thanks,
Jason
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Juha Laiho <Ju...@iki.fi>.
Jason Cipriani wrote:
> I have a web application with a lot of configuration options, all
> currently stored as servlet initialization parameters in
> WEB-INF/web.xml. The parameters are site specific and are different
> for my development machine, the machines of the two other developers
> working on the project, and the production machine. I am the only
> developer working on the web application.
There's one conceptual issue you'll need to look at, namely
that of separation the environment-dependent configuration
from the environment-independent one. At the first, making the
distinction between the two can be problematic, and there may
well be bordercases - those you'll just need to decide.
With this strategy, I have applications that I can move trhough the
chain from development to testing to production without touching
the .war file contents -- and it's very rare to have a situation
where an application change would require a change in the
environment-dependent configuration.
> Similarly, I have a JDBC data source defined in META-INF/context.xml.
> The data source parameters are different for each machine. Is there
> some other way I can define data sources so that I don't have to
> maintain separate WAR files for each configuration?
Take the context.xml out of the webapp; it wasn't meant to be there.
With Tomcat, conf/Catalina/[hostname]/[appname].xml is a better
place. If there's something you can't place in that file, at least
create a variable in context.xml that does point to the external
resource (file, server, whatever). If you have multiple applications
dependent on some single, poolable resource (common database schema,
for example), it would be better to place the JDBC datasource definition
into server.xml, and put instead a <ResourceLink> element into each
of the per-application context.xml files. That way, you'll have
a single pool serving the various applications (this of course
requires that all the applications play fair and do not leak; a sinlge
leaky application can starve other applications by hogging all
instances of a shared resource.
> Ideally I'd be able to put the settings in context.xml and web.xml
> somewhere outside of the web application directory, and leave them out
> of the web-app's local files, and so they wouldn't have to be packaged
> with the WAR and deploying the WAR wouldn't blow away existing
> configuration data.
web.xml can also be configurable -- but leave there the aspects of
configuration you'd otherwise put as fixed parameters into your
source code, to be determined at compile time.
--
..Juha
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Convenient web application configuration.
Posted by br1 <my...@myrealbox.com>.
Hi,
Caldarale, Charles R wrote:
>
>> From: br1 [mailto:myrealbruno@myrealbox.com]
>> Subject: Re: Convenient web application configuration.
>>
>> The easiest way is to place Context and the different
>> Resource elements into each Tomcat's server.xml file.
>
> Certainly not "easiest" by any definition of the term that I'm familiar
> with, especially in a production environment.
>
It probably depends on requirements. I am familiar calling it the "easiest"
and I manage production environments.
Caldarale, Charles R wrote:
>
> 1) Restart of Tomcat (not just the webapp) required when *any* changes are
> needed.
>
It just takes a few seconds, and *any* change is done first in the
development environment. When the test environment is happy, the production
one is just restarted once.
Also, do you mean "deploy a webapp under Windows without restarting Tomcat"?
Caldarale, Charles R wrote:
>
> 2) Sysadmins don't like app developers mucking with server configurations.
>
Absolutely! I did not mean this at all.
I mean that some sysadmins are happy to waste their time to fix these
details themselves for exactly this reason.
And they don't like app developers deciding the app path, nor they like app
developers decide where their log files should go or where, for instance, a
full text index should stay. The list is long, and no one forgot database
connections.
Caldarale, Charles R wrote:
>
> 3) Doesn't bundle the webapp-specific configuration with the webapp.
>
Making the webapp point to a development or production database is not
specific to the webapp at all. It is specific to the environment (the
"context") that the webapp is running on. Same applies to other resources as
I mentioned above.
Another reason you want to do it: you want connection pooling at the Tomcat
instance level, and you use a global JNDI resource, that means "edit the
server.xml". (Thunder here)
Caldarale, Charles R wrote:
>
> 4) Error prone due to the manual editing required.
>
> - Chuck
>
Just like any other file the sysadmin edits.. also see point (1).
In no case I was suggesting an app developer to edit files, other than the
development environment.
br1
--
View this message in context: http://www.nabble.com/Convenient-web-application-configuration.-tp20244034p20256710.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Convenient web application configuration.
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: br1 [mailto:myrealbruno@myrealbox.com]
> Subject: Re: Convenient web application configuration.
>
> The easiest way is to place Context and the different
> Resource elements into each Tomcat's server.xml file.
Certainly not "easiest" by any definition of the term that I'm familiar with, especially in a production environment. Immediately obvious drawbacks:
1) Restart of Tomcat (not just the webapp) required when *any* changes are needed.
2) Sysadmins don't like app developers mucking with server configurations.
3) Doesn't bundle the webapp-specific configuration with the webapp.
4) Error prone due to the manual editing required.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by br1 <my...@myrealbox.com>.
jason cipriani-2 wrote:
>
>
> Ideally I'd be able to put the settings in context.xml and web.xml
> somewhere outside of the web application directory, and leave them out
> of the web-app's local files, and so they wouldn't have to be packaged
> with the WAR and deploying the WAR wouldn't blow away existing
> configuration data.
>
>
Jason,
The easiest way is to place Context and the different Resource elements into
each Tomcat's server.xml file.
Someone will tell you that it's not recommended, but it will just work.
Hope it helps,
br1
--
View this message in context: http://www.nabble.com/Convenient-web-application-configuration.-tp20244034p20252816.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Convenient web application configuration.
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Jason Cipriani [mailto:jason.cipriani@gmail.com]
> Subject: Convenient web application configuration.
>
> Is there a better place I can store site-specific
> configuration options?
Read the doc:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Context%20Parameters
> Is there some other way I can define data sources so
> that I don't have to maintain separate WAR files for
> each configuration?
The <Resource> element must go inside a <Context> element, but you can place the <Context> in conf/Catalina/[host]/[appName].xml rather than in the webapp's META-INF/context.xml file. Again, read the doc:
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Introduction
Your deployment script will need to copy the site-specific file containing your <Context> element to conf/Catalina/[host]/[appName].xml since that file is removed when a webapp is undeployed.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Jason Cipriani <ja...@gmail.com>.
Hmm, well, there are no other web applications, the server is
dedicated to this one. If there *were* other web applications, they
would likely be using the same data source anyways -- and in that case
it's certainly handy to be able to set the data source for multiple
web apps by maintaining just a single entry in one of Tomcat's
configuration files. Also, for now, I did name the resource something
unique to the web application, I'm not worried about conflicts. As for
management, simple instructions "insert this into context.xml on new
server setup" seems to be working out well.
I can't think of any way that's more convenient. IMHO, if the choice
is writing custom deployment scripts and having to maintain and run
those to deploy the web app (and centrally maintaining separate copies
of configuration files so they can be distributed with the deployment
scripts rather than letting other developers maintain their own), and
describe to other developers how those work vs. adding an entry to
context.xml once and using Tomcat manager to deploy things, it seems
that the former ends up being more confusing and hard to manage.
To be honest I can't think of a single compelling reason not to do it
this way, or any reason at all other than the fact that I have to
explain to developers that when setting up a new system, they must
modify Tomcat configuration files, and I don't see that as a big deal.
I could be missing something, but everything is working great and is
incredibly easy to manage now that I've made this change. That seems
positive.
Jason
On Thu, Nov 6, 2008 at 5:23 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jason,
>
> Jason Cipriani wrote:
>> My end solution ended up being to modify
>> $CATALINA_ROOT/conf/context.xml and put the JNDI data source
>> definition there.
>
> Yikes! You should /definitely/ not do that. Doing so will make that JNDI
> data source available (separately, I might add) to all deployed
> applications. You'd be better off putting it in server.xml, since nobody
> really ever looks for anything in the server-wide context.xml. I believe
> you will be adding confusion at the least and a management nightmare at
> the worst.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkTbmgACgkQ9CaO5/Lv0PBg4gCgpjHTTBCbQDvesDsgYh7ork8i
> 11YAn2d/Hx2erPtBGBdxrkVjLwAY97Wr
> =4mqt
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason,
Jason Cipriani wrote:
> My end solution ended up being to modify
> $CATALINA_ROOT/conf/context.xml and put the JNDI data source
> definition there.
Yikes! You should /definitely/ not do that. Doing so will make that JNDI
data source available (separately, I might add) to all deployed
applications. You'd be better off putting it in server.xml, since nobody
really ever looks for anything in the server-wide context.xml. I believe
you will be adding confusion at the least and a management nightmare at
the worst.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkTbmgACgkQ9CaO5/Lv0PBg4gCgpjHTTBCbQDvesDsgYh7ork8i
11YAn2d/Hx2erPtBGBdxrkVjLwAY97Wr
=4mqt
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Jason Cipriani <ja...@gmail.com>.
My end solution ended up being to modify
$CATALINA_ROOT/conf/context.xml and put the JNDI data source
definition there. While I agree that modifying global server files is
less than ideal it is by far the simplest solution: It's only one
resource element that has to be added, it requires no modification to
deployment scripts, and solves the problem of site-specific data
source.
I left non site-specific servlet context configuration in each
servlet's web.xml.
Then, I moved site-specific servlet context parameters into the
database. This ended up working out really nicely for a number of
reasons.
Everything is much more convenient now. Thanks for all your advice.
Jason
On Tue, Nov 4, 2008 at 5:15 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jason,
>
> Jason Cipriani wrote:
>> I'm developing with Eclipse but could configure custom build steps
>> with ant. This solution would remove most of the inconvenience, but I
>> would still have to make 4 separate WARs available for distribution.
>> Not *too* big of a deal but I'd rather just distribute a single
>> archive.
>
> If you need a different web.xml file for each machine, they you will, by
> definition, require a different WAR for each machine. There's really
> nothing you can do about that.
>
> Another option would be to configure your application using something
> other than web.xml.... but then you've just moved the problem to another
> file.
>
> We use a file in the user's home directory (called .ant.properties) that
> includes machine-specific environmental information. To deploy, we grab
> the source from CVS and run "ant install" which does everything,
> including merging the machine-specific configuration into the WAR and
> deploying it. We have a small number of production machines, so this
> isn't a big deal for us. If we had a large number, we'd just further
> script the process by allowing the WAR creation to be parameterized by,
> say, command-line switches (which they really are, since you can define
> any ant property right on the command-line).
>
> Hope that helps,
> - -chris
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkkQyYEACgkQ9CaO5/Lv0PBzXQCdH4lqz0vHbGOChbEJIihowz50
> 2lsAoK6obiLTx09nSb7+8taZxxITlpjM
> =GAv3
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jason,
Jason Cipriani wrote:
> I'm developing with Eclipse but could configure custom build steps
> with ant. This solution would remove most of the inconvenience, but I
> would still have to make 4 separate WARs available for distribution.
> Not *too* big of a deal but I'd rather just distribute a single
> archive.
If you need a different web.xml file for each machine, they you will, by
definition, require a different WAR for each machine. There's really
nothing you can do about that.
Another option would be to configure your application using something
other than web.xml.... but then you've just moved the problem to another
file.
We use a file in the user's home directory (called .ant.properties) that
includes machine-specific environmental information. To deploy, we grab
the source from CVS and run "ant install" which does everything,
including merging the machine-specific configuration into the WAR and
deploying it. We have a small number of production machines, so this
isn't a big deal for us. If we had a large number, we'd just further
script the process by allowing the WAR creation to be parameterized by,
say, command-line switches (which they really are, since you can define
any ant property right on the command-line).
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkQyYEACgkQ9CaO5/Lv0PBzXQCdH4lqz0vHbGOChbEJIihowz50
2lsAoK6obiLTx09nSb7+8taZxxITlpjM
=GAv3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Jason Cipriani <ja...@gmail.com>.
On Thu, Oct 30, 2008 at 8:22 AM, Pid <p...@pidster.com> wrote:
> Is your build process automated, say with ant or maven?
> If so, it should be a relatively simple one-off job to configure
> multiple output war files from one codebase with several configurations.
I'm developing with Eclipse but could configure custom build steps
with ant. This solution would remove most of the inconvenience, but I
would still have to make 4 separate WARs available for distribution.
Not *too* big of a deal but I'd rather just distribute a single
archive.
On Thu, Oct 30, 2008 at 9:44 AM, Caldarale, Charles R
<Ch...@unisys.com> wrote:
> Read the doc:
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Context%20Parameters
...
> The <Resource> element must go inside a <Context> element, but you can place the <Context> in conf/Catalina/[host]/[appName].xml rather than in the webapp's META-INF/context.xml file. Again, read the doc:
> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Introduction
>
> Your deployment script will need to copy the site-specific file containing your <Context> element to conf/Catalina/[host]/[appName].xml since that file is removed when a webapp is undeployed.
Thanks for the advice and the doc link, this looks like the best
option. I was deploying the WAR through the Tomcat manager, I'll have
to change that (unless there's a way to configure custom deployment
steps through the manager?). Is there a way to keep it from being
removed when the app is undeployed?
On Thu, Oct 30, 2008 at 2:32 PM, br1 <my...@myrealbox.com> wrote:
> The easiest way is to place Context and the different Resource elements into
> each Tomcat's server.xml file.
> Someone will tell you that it's not recommended, but it will just work.
That's not a bad idea, except it seems I can get around all of the
drawbacks Chuck mentioned with the low cost of putting the file in
conf/Catalina/[host]/[appName].xml instead. Although it's enticing,
since it's something I'd only have to set up once per server and not
think about again. For now this server is dedicated to a single web
application so restarting the server is not any worse than restarting
the web app.
Thanks for your replies,
Jason
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Pid <p...@pidster.com>.
Jason Cipriani wrote:
> I'm using Tomcat 6.0.18 on Windows XP SP3, Windows Server 2003, and
> Windows Vista (UAC disabled).
>
> I have a web application with a lot of configuration options, all
> currently stored as servlet initialization parameters in
> WEB-INF/web.xml. The parameters are site specific and are different
> for my development machine, the machines of the two other developers
> working on the project, and the production machine. I am the only
> developer working on the web application.
>
> My problem is that web.xml is part of the web application WAR file.
> Also web.xml differs for the 4 different machine the web application
> runs on. This means that every single time I make a release, I have to
> comment and uncomment blocks of parameters in web.xml, build 4
> separate WAR files customized for each machine, and make the 4
> separate WAR files available to each of the 4 people running the web
> application. This is very cumbersome and it seems unreasonably
> complicated, and has already led to a number of distribution mistakes
> on multiple occasions. Is there a better place I can store
> site-specific configuration options? Any suggestions would be helpful.
>
> Similarly, I have a JDBC data source defined in META-INF/context.xml.
> The data source parameters are different for each machine. Is there
> some other way I can define data sources so that I don't have to
> maintain separate WAR files for each configuration?
>
> Ideally I'd be able to put the settings in context.xml and web.xml
> somewhere outside of the web application directory, and leave them out
> of the web-app's local files, and so they wouldn't have to be packaged
> with the WAR and deploying the WAR wouldn't blow away existing
> configuration data.
Is your build process automated, say with ant or maven?
If so, it should be a relatively simple one-off job to configure
multiple output war files from one codebase with several configurations.
If not, I'd recommend you look into them (I prefer ant, but YMMV).
p
> Thanks,
> Jason
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Convenient web application configuration.
Posted by Bill Barker <wb...@wilshire.com>.
"Jason Cipriani" <ja...@gmail.com> wrote in message
news:c09049bf0810300323q3d7df8fcs80c407eefea14472@mail.gmail.com...
> I'm using Tomcat 6.0.18 on Windows XP SP3, Windows Server 2003, and
> Windows Vista (UAC disabled).
>
> I have a web application with a lot of configuration options, all
> currently stored as servlet initialization parameters in
> WEB-INF/web.xml. The parameters are site specific and are different
> for my development machine, the machines of the two other developers
> working on the project, and the production machine. I am the only
> developer working on the web application.
>
> My problem is that web.xml is part of the web application WAR file.
> Also web.xml differs for the 4 different machine the web application
> runs on. This means that every single time I make a release, I have to
> comment and uncomment blocks of parameters in web.xml, build 4
> separate WAR files customized for each machine, and make the 4
> separate WAR files available to each of the 4 people running the web
> application. This is very cumbersome and it seems unreasonably
> complicated, and has already led to a number of distribution mistakes
> on multiple occasions. Is there a better place I can store
> site-specific configuration options? Any suggestions would be helpful.
>
This is specific to Tomcat, but Tomcat will do System variable replacement
while parsing web.xml. So you would do something like:
<init-param>
<param-name>foobar</param-name>
<param-value>${myapp.foobar}</param-value>
</init-param>
Then each of the 4 just have to include a -Dmyapp.foobar=value when starting
up Tomcat.
> Similarly, I have a JDBC data source defined in META-INF/context.xml.
> The data source parameters are different for each machine. Is there
> some other way I can define data sources so that I don't have to
> maintain separate WAR files for each configuration?
>
> Ideally I'd be able to put the settings in context.xml and web.xml
> somewhere outside of the web application directory, and leave them out
> of the web-app's local files, and so they wouldn't have to be packaged
> with the WAR and deploying the WAR wouldn't blow away existing
> configuration data.
>
> Thanks,
> Jason
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org