tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <>
Subject Re: Context parameter override?
Date Wed, 10 Sep 2014 22:45:48 GMT
Hash: SHA1

Responses inline.

On 9/10/2014 1:33 PM, wrote:
> I am pretty sure I tried option 3 and Log4j initialization did
> ignore my log4jConfigLocation setting in conf/.../myapp.xml.

Oh heck, I think I see what you're trying to do. And this isn't going
to work for multiple web applications, since it's a SYSTEM property.

This means you get 1 value for the JVM. The following web page
illustrates this:

Read the section called Default Initialization under Tomcat.

Also, what you're configuring is a context initialization parameter
with <Parameter> and NOT a system property.

In short, if you're trying to direct log4j to read the log4j.xml (or
properties) file from another location, setting a context
initialization parameter will get you absolutely nowhere.

> What I tried to see in the debug log is the list of context
> parameters picked up at start time. Despite log level was set to
> FINEST nothing show up in any of the Tomcat logs related to my
> parameter declaration. I shall look into the Tomcat code to
> understand this.

It's not an issue with the Tomcat code. It's how log4j goes about
finding its configuration file.

log4j uses Thread.getContextClassLoader().getResource() to find the
log4j.xml (or properties) file. This means that the file must be in
your classpath. In Tomcat, the search works its way up the class
loader hierarchy.  See the following link for how the class loaders
are searched.

If you want the following:

1. per-application control over log4j logging
2. run-time (as in while the application is running) control
3. thread safety, reliability, and no thread leaks

You will need to do the following:

1. implement a JMX listener to publish the log levels
2. set reasonable levels in log4j.xml found in the context's classpath
3. use a JMX utility to change the log levels during operation

If you want the following:

1. per-application control over log4j logging
2. change log levels while the application is not running

Then you have some options (and I hope you start / stop logging in a
servlet context listener).

Place the log4j.xml (or properties) file in the WAR file. When it's
deployed (if the WAR is exploded), you can then edit it and restart
the context.

Place the log4j.xml (or properties) file outside the WAR file and do
the following (again, this will have to be facilitated by the Dev group):

1. Create a context init parameter (most easily in the Parameter
   element in context.xml).

2. The init parameter will give the path to the file

3. Read that parameter in a servlet context listener

4. Pass that to the Configurator's configure(String filename) method

Again, you will have to tell log4j to find the configuration some
place other than it normally looks (classpath or the SYSTEM property

Here's how I manage things.

1. Maven project for deploy
   a. accepts a parameter to select appropriate logging levels
   b. this selects a properties file to filter a log4j template
   c. properties file is under version control
   d. accepts a parameter for the version to deploy
   e. accepts a parameter for where to deploy
2. Parameterized Jenkins job
   a. runs the Maven project
   b. drop-down menu for IT (internal test), UAT, PROD
   c. drop-down menu for version (no SNAPSHOTS in PROD!)
   d. sends email to dev responsible, ops, business lead
      1. what was deployed
      2. where it was deployed
      3. when it was deployed
      4. who deployed it (no shared accounts on Jenkins)

I use parallel deployment with Tomcat 7 and use the Jenkins build
number to increment the value.

I'm working on updating the incident tracking system automatically
from Jenkins, but I'm just learning Groovy and the tracking system
doesn't have a robust API.

. . . just my two cents

>> Date: Thu, 11 Sep 2014 00:20:19 +0400 Subject: Re: Context
>> parameter override? From: To:
>> 2014-09-10 21:52 GMT+04:00  <>:
>>> (...)
>>> What puzzles me is the Context / Parameter feature of Tomcat.
>>> (context-param from Java is clear.) There are at least 3
>>> locations to define Tomcat level parameters:
>>> - server.xml / Host   (1) - webapps / ... / context.xml  (2) -
>>> conf/.../myapp.xml (3)
>>> None of these I managed to configure.
>> (1) - wrong. You should not define a Context there.
>> In Tomcat 6 that you are using, the META-INF/context.xml file (2)
>> is automatically copied into conf directory of Tomcat (3) when
>> the web application is being deployed. Once that copying happens
>> modifying the webapp's file (2) becomes useless. You have to
>> modify the copy.
>> This copyXml feature was turned off starting with Tomcat 7.

Version: GnuPG v1.4.13 (MingW32)


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

View raw message