RE: Where to set exernal property referred to in log4j.properties

[Jacob Kjome <ho...@visi.com>]

At 06:00 PM 6/7/2005 +0530, you wrote:
 >
 >Hi Jacob,
 >
 >What is autoconfiguration?

As James said, refer to the docs (link provided in his response)

 >I am using the same solution as you have suggested below for the same
 >problem that I want the log file path to contain ${MY_APP_HOME} e.g.
 >${MY_APP_HOME}\logs\logfile.log.
 >But it is not working. I am using Websphere5.0.
 >1. I have set an OS environment variable MY_APP_HOME=3D"C:\myapp"
 >2. Implemented ServletContextListener and in contextInitialized() method
 >got the value of this OS env var and set it into JVM properties.
 >3. The log4j.xml  file contains the log file path as
 >${MY_APP_HOME}\logs\logfile.log.
 >
 >What is going wrong. One thing I have noticed from the logs is that,
 >log4j system is trying to initialize before the ServletContext is
 >initialized.
 >

Actually, I mentioned this below.  If you have the config file in the 
classpath, log4j will autoconfigure itself in a static block.  This will 
happen before your servlet context listener has a chance to do 
anything.  What I tend to do is put a dummy log4j.xml config file in the 
classpath which is minimal and pretty much turns off all logging in the 
root logger, and then perform manual configuration.  Having the file in the 
classpath makes sure no other log4j config file get picked up (in case some 
library is improperly placing their own config file in the classpath).  In 
any case, the manual configuration afterward should have reset the logging 
configuration so your config should have worked.

BTW, the point about the OS system variable was more so you can set 
CATALINA_OPTS (speaking of Tomcat here) once and be done.  Then, if you 
change a path, CATALINA_OPTS will pick it up automatically.  It was sort of 
an aside.  The main thing is that you can set -D parameters which will set 
JVM system properties, such as "-DMY_APP_HOME=/path/to/app".  In that case, 
autoconfiguration would pick that system property up because it would exist 
before the Log4j static block runs autoconfiguration.

One other thing to check is that the "/path/to/app/logs" directory 
exists.  If you are expecting Log4j to create it for you if it doesn't 
already exist, you are mistaken.  Log4j makes no attempt to create 
directories.  That is your code's responsibility to do before configuration 
takes place.

Jake

 >Please help.
 >
 >Regards,
 >Jitendra
 >
 >-----Original Message-----
 >From: Jacob Kjome [mailto:hoju@visi.com]
 >Sent: Friday, March 25, 2005 8:44 PM
 >To: Log4J Users List
 >Subject: RE: Where to set exernal property referred to in
 >log4j.properties
 >
 >At 09:33 AM 3/25/2005 -0500, you wrote:
 > >Thanks for the reply, James.  I agree with you that it wouldn't be
 >>non-standard but since I don't maintain our tomcat implementation I was
 >>looking to see if there might be another way.
 >
 >Have you looked into using CATALINA_OPTS?  Just set said variable as an
 >OS system property and provide any command line arguments you want.
 >Tomcat's scripts will pick this up and add it to the Tomcat startup
 >script.  This means you can add custom command line args without having
 >to change the Tomcat distribution at all.
 >
 >You can also use a ServletContextListener to set up a system property,
 >which you refer to the log4j config file, before manual configuration is
 >performed.  Note that autoconfiguration probably would not work in this
 >case since the system property will have been set *after*
 >autoconfiguration has taken place.
 >
 > >
 > >Maybe making the logs relative to catalina.home is the right idea.  I
 >>suppose that my only concern though is that I'm using my primary log
 >file by  >both my web application and another external java application
 >code.  I  >mentioned this a couple days ago and someone suggested that
 >sharing one log  >file between two applications is a bad idea and that
 >the logs would become  >garbled.  Is that really so?  I thought that it
 >was OK to share a log  >between different JVMs since the log includes
 >thread identifiers.
 > >
 >
 >As I understand it, the only time you need to worry about File
 >contention is between two separate JVM's.  However, you will need to
 >make sure that in one config file you don't set the FileAppender to
 >append=true and append=false in another.  So, you might want to point at
 >different files per application even if there is no thread level file
 >contention.  You can still log you files relative to catalina.home (or
 >catalina.base), since that is a JVM system variable that Tomcat provides
 >for you automatically at startup.
 >
 >Jake
 >
 > >I'm probably going to move the applications that are outside the web
 >>application to a model whereby they are executed from URLs anyway so in
 >the  >future I suppose that risk will be mitigated.
 > >
 > >
 > >-----Original Message-----
 > >From: James Stauffer [mailto:stauffer.james@gmail.com]
 > >Sent: Friday, March 25, 2005 8:38 AM
 > >To: Log4J Users List; wnoto@openfinance.com
 > >Subject: Re: Where to set exernal property referred to in
 >log4j.properties  >  >On Fri, 25 Mar 2005 00:37:46 -0500, William Noto
 ><wn...@openfinance.com>
 > >wrote:
 > >> My operations team is concerned about setting the property
 >externally at  >the  >> user level when we start Tomcat because they do
 >not want to run a  >> non-standard implementation.
 > >That is equivalent to setting an environement variable and wouldn't
 >>make it a "non-standard implementation."
 > >
 > >>  I have tried a number of things that I thought  >> might work
 >including setting the property through the web.xml's  >> context-param
 >tag and setting it in the <context> at the server.xml level  >> but
 >always without success.
 > >Can you just use a relative path or chose a path relative to
 >>${catalina.home} ?
 > >
 > >--
 > >James Stauffer
 > >Are you good? Take the test at http://www.livingwaters.com/good/  >
 > >---------------------------------------------------------------------
 > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
 > >For additional commands, e-mail: log4j-user-help@logging.apache.org
 > >
 > >
 > >
 > >---------------------------------------------------------------------
 > >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
 > >For additional commands, e-mail: log4j-user-help@logging.apache.org
 >
 >
 >---------------------------------------------------------------------
 >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
 >For additional commands, e-mail: log4j-user-help@logging.apache.org
 >
 >
 >---------------------------------------------------------------------
 >To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
 >For additional commands, e-mail: log4j-user-help@logging.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org