tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: install war with xml and define environment values
Date Mon, 02 Dec 2013 22:26:25 GMT
Hash: SHA256


On 12/2/13, 11:23 AM, Mark Eggers wrote:
> On 12/1/2013 10:49 PM, Philipp Kraus wrote:
>> Hello,
>> Am 01.12.2013 um 23:40 schrieb Mark Eggers
>> <>:
>>> Run Tomcat as an unprivileged user.
>>> If you need to have Tomcat serve on port 80, use jsvc, iptables
>>> to map port 80 to port 8080, or place an Apache HTTPD server in
>>> front of Tomcat using mod_proxy_http, mod_proxy_ajp, or
>>> mod_jk.
>>> You could also unpack the WAR file, change the param value,
>>> and repackage the WAR file. Of course, the user Tomcat is
>>> running under will need to have privileges to the directory you
>>> change the param value to.
>> On my test system Tomcat 7 runs with root access, but on my 
>> production system it runs with an unprivileged user on port 9090
>> and a Nginx works like a proxy for https. This works fine, but on
>> the Tomcat runs Jenkins and a project planning system. My
>> Jenkins installation is configures by a XML file in the
>> /etc/tomcat7 directory with this content:
>> <Context docBase="/usr/share/jenkins/jenkins.war"
>> privileged="true" allowLinking="true" crossContext="true"
>> autoDeploy="true" > <Environment name="JENKINS_HOME"
>> value="/home/jenkins/" type="java.lang.String"/> </Context>
>> With the value JENKINS_HOME I can change the data directory of 
>> Jenkins.
>> The project planning system uses only ${user.home}, so I would
>> like to redefine this environment value for this war only
>> (because the backup system runs over the /home dir). I'm working
>> the first time with tomcat but not with java.
>> Thanks Phil
> I don't know about your project planning system, but my
> installation of Jenkins doesn't need crossContext, privileged, or
> allowLinking. I'm not sure what autoDeploy accomplishes as a
> Context attribute (nothing?).

It produces a lovely warning message.

> Do other people use your machine, or are you the sole user?
> If you're the sole user, set up Tomcat within your home directory,
> take the defaults, drop the WAR files in $CATALINA_BASE/webapps,
> and you're done.
> If not, then set up your system much like your production system.
> That way others can access it on port 80, the unprivileged user
> gets everything backed up (provided the account is in
> /home/unprivileged), and again you can just take the defaults.
> This really is a Java issue and not a Tomcat issue. The application
> is using the environment variable user.home. Setting aside whether
> this is a good idea or not, I think you have a few alternatives (if
> you don't set things up as above).


<Environment> doesn't do what the OP thinks it does. OP wants to
redefine a *system property* when running a particular web
application, but not affect that value for other applications running
in the same JVM. This is simply not possible.

Phillipp, you've mentioned 3 different ways to configure things:

1. Using web.xml <init-param>
2. Using context.xml <Environment>
3. Using ${user.home} system property

It's unclear to me which of these you actually want to use and for
what. You have mentioned both Jenkins (which ought to be configurable
in a number of ways, given the wide range of environments in which it
is probably run) and an otherwise unspecified "project planning system".

Is Jenkins simply a red herring?

If your project planning system (that's the one you want to
reconfigure, right?) reads the system property "user.home", then you
are simply going to have to change it to read something else unless
you want to redefine the value of "user.home" for the entire JVM.

> 1. Unpack the WAR, change the param, repack the WAR, run the
> altered WAR
> This may or may not work, and depends on whether the application
> uses System.getenv("user.home") elsewhere to write to the
> directory.

The most straightforward to code would be to read <init-param> from
web.xml using ServletContext.getInitParameter. But, as you've
mentioned, changing an init-param's value within a WAR is kind of a
PITA. If you use <Environment> in your webapp's META-INF/context.xml
(or CATALINA_BASE/conf/[Engine]/[Host]/[webapp].xml) then that *can*
be easier to configure (if you put your file in conf/ as shown above)
but then the code for fetching values from JNDI is semi-awkward.

> 2. Set the environment variable user.home
> I don't know what other impacts this will have. You can do this by
> the following:
> a. create a file called in $CATALINA_BASE/bin b. in that
> file put something like the following:
> CATALINA_OPTS="-Duser.home=some-location" export CATALINA_OPTS

Phillip could also do something crazy like inventing a *new* system
property that only his application cares about. How about
project.planning.user.home, or whatever makes more sense for you?


Now modify your code to read the system property
"project.planning.user.home" and be done with it. There's no need to
try to figure out how to make "user.home" look different to multiple

This is a fairly clear case of holding a nail and looking everywhere
for a hammer when you clearly need to decide that a screw is more
appropriate and use the screwdriver you already have in your other hand.

- -chris
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message