-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comments inline.
Conventions for this list are to post replies at the end or inline. It makes reading the thread easier. On 9/10/2014 10:52 AM, sbre...@hotmail.com wrote: > Thanks, I am afraid I read a similar solution earlier which I did > not favour for multiple reasons: > > - it is a run-time configuration question (handled by DevOps, Ops) > to have various logging levels for various deployed applications on > the same Tomcat This is quite possible for the solution I proposed. Each application has its own [appname].xml, so the logging can be changed per application. > - we would like to have full control of logging (which class at > what level etc.) during run-time, i.e. be able to have per web > application Log4j configuration file Ah, during run-time. I didn't see that requirement in your original message. That's an entirely different kettle of fish. The Parameter element of the Context is a Tomcat-specific way to specify context initialization parameters. As implied by the name "context initialization", they're read once at context start-up and made available to the context. Changing them through the life cycle of that context is not possible. You would have to edit the appname.xml and restart the context. See my JMX comments to André concerning how to do this on a running application. I've hacked together a listener that exposes all of the log4j information as JMX (based on the following blog post: http://www.jroller.com/ray/entry/managing_log4j_logging_levels_for). I then was able to modify the various loggers during run time using JConsole. Obviously you'll need some sensible initial values. > - writing servlet is beyond the scope of our responsibility > (DevOps, Ops) I agree. You will need the developers to get involved in order to provide the mechanism for you. I don't know of any configuration-only mechanism to accomplish this . . . Hmm . . . hang on a second. If log4j is configured using configureAndWatch (available via DOMConfigurator and PropertyConfigurator), then a thread is spawned to watch the configuration file for changes. Since this method starts a watchdog thread and there's no way to stop it in log4j 1.2.x (according to the log4j FAQ), this should not be used in a J2EE environment where the applications are recycled. > - keep the Dev and Ops responsibilities separated Agreed. This is why I think Dev needs to give Ops the handles to tweak the logging levels (most likely via JMX). > > 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 - webapps / ... / context.xml - > conf/.../myapp.xml > > None of these I managed to configure. Is there any working example > from Tomcat? They all work. Doing this at in server.xml means that you'll have to restart the server when the values change. Doing this in context.xml (appname.xml) means that you'll have to restart the application when the values change. > > Shall I recommend Dev to hard code a path to the Log4j > configuration in web.xml, i.e. /usr/local/etc/myapp_log4j.xml, > which is potentially a symbolic link to an actual file that can > stay anywhere on the file system? No. See above concerning the safety and applicability of using configureAndWatch in a J2EE environment. Changing log4j.xml on the fly will create thread leaks. Who knows what the environment will be like once you reload multiple applications using configureAndWatch. . . . just my two cents /mde/ > >>> Date: Wed, 10 Sep 2014 09:03:59 -0700 From: >>> its_toas...@yahoo.com.INVALID To: users@tomcat.apache.org >>> Subject: Re: Context parameter override? >>> > On 9/10/2014 8:40 AM, sbre...@hotmail.com wrote: >>>>>> Hello >>>>>> >>>>>> We have a setup which compiles WAR applications once and >>>>>> deploys them in various environments. Each environment >>>>>> has its own per application Log4j configuration (WARN for >>>>>> production, DEBUG for development etc.) which should >>>>>> survive application redeployment. >>>>>> >>>>>> So far the solution is: >>>>>> >>>>>> webapps/myapp/WEB-INF/web.xml >>>>>> >>>>>> ... <context-param> >>>>>> <param-name>log4jConfigLocation</param-name> >>>>>> <param-value>file:///opt/tomcat6/conf/myapp/log4j.xml</param-value> >>>> >>>>>> >> >>>>>> >>>>>> > </context-param> >>>>>> ... >>>>>> >>>>>> Pretty standard, works. >>>>>> >>>>>> Question is, how can I make sure the Log4j configuration >>>>>> path is not hard coded in the 'web.xml' at development >>>>>> time. Idea was: >>>>>> >>>>>> webapps/myapp/META-INF/context.xml ... <Parameter >>>>>> name="log4jConfigLocation" value="file://TBD" /> ... >>>>>> >>>>>> and change it after the application deployment: >>>>>> >>>>>> conf/Catalina/localhost/myapp.xml ... <Parameter >>>>>> name="log4jConfigLocation" >>>>>> value="file:///opt/tomcat6/conf/myapp/log4j.xml" /> ... >>>>>> >>>>>> Tomcat simply ignores both of these context XML files, or >>>>>> at least the parameters defined in them. I read through >>>>>> all mailing lists, all documentations, switched on debug >>>>>> to the 'finest' level, still no avail. How difficult can >>>>>> this be? >>>>>> >>>>>> Details: >>>>>> >>>>>> Server version: Apache Tomcat/6.0.35 Server built: Nov >>>>>> 28 2011 11:20:06 Server number: 6.0.35.0 OS Name: >>>>>> Linux OS Version: 2.6.18-348.el5 Architecture: amd64 >>>>>> JVM Version: 1.6.0_30-b12 JVM Vendor: Sun >>>>>> Microsystems Inc. >>>>>> >>>>>> >>>>>> Cheers B. >>>>>> > > I'm just noodling - haven't tried this. Your mileage may vary, > void where prohibited, etc., etc., etc. > > How about: > > 1. use Parameter in context.xml to set the logging level: > > <Parameter name="LoggingLevel" value="DEBUG" override="false"/> > > 2. Write a servlet context listener to read the parameter > > 3. Set the logging level accordingly > > Place the servlet context listener as the first one in your web.xml > so the new logging level is set before any other logging occurs. > > This way your log4j.xml doesn't have to change, and you can just > use an appropriate > $CATALINA_BASE/conf/Catalina/[hostname]/[appname].xml to set the > desired logging level. > > This seems as if it should work. > > . . . just my two cents /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (MingW32) iQEcBAEBAgAGBQJUEKbuAAoJEEFGbsYNeTwtL3gIAIj6O+4kPKP+OyCk8JLXpcXS mqHoJ16L/903BATHSqdVZ9KA8B5l9EQJMVQ3ULmqzL61bJ0fh2jv8RrspL0mlw3l 68Coy+WyLpq+tG0uukbADxb8dTx9nFLSKY+2m4UZmviMsGjYnTLy6kJDy/NAk23p S9esDtzXIx92n04UVNPd1sUbrk5maNwTYfC0jryZFSOVqR8TeRa/K0BTjVFV83Wx W01M3wtkOwOa+sibRtTSrX6dIqGNI2W/lYWANelDaVywwLdbMw4O0VMpycV9WfKF 7NQ0/COzCcfMr5uRbQ8hHcJKuyKu9fY4EWvrgdKJirT2DrmUbOwKSvvHLloMqNs= =Vpxe -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
