-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Responses inline.
On 9/10/2014 1:33 PM, sbre...@hotmail.com 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: http://logging.apache.org/log4j/1.2/manual.html 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. http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html 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 log4j.configuration). 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 /mde/ > >> Date: Thu, 11 Sep 2014 00:20:19 +0400 Subject: Re: Context >> parameter override? From: knst.koli...@gmail.com To: >> users@tomcat.apache.org >> >> 2014-09-10 21:52 GMT+04:00 <sbre...@hotmail.com>: >>> >>> (...) >>> >>> 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUENScAAoJEEFGbsYNeTwt+lwH/iUxrY8FoVTmK2hK4ewPOhNs ITtQIedgUDGHihTw2nKCVq/rtSGm+fp0nJHqcyPthw6dNWItnyd6+kaJrOV3ZRsH zlRZOYWMAxd5i1IJunzOYBVcO0WZVjIheyuEF0wNQg03p3V68rpHkIsp4B2QWTZ0 mMPjEbFe7jEHgqrHMF6honENyB/35QKR0Q6atJo/n/XC/54lYVD93ebYufXDFj8o hFMQvIfEth7tzxhpqM1wKOYgtBEPnSF9m3WQ/zCGw2JDPG7gJIJp7OSrxcjMo/7/ ARM7Qh6ThnVIce8vM/80DxGpNGUM1eo1bXXZ1JAKu15ZU2nCAhZn+2WM+1O9z0U= =4Tt8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
