RE: Spam:Re: Reading config.xml from jarfile

[Bruno Melloni <Br...@akuratus.com>]

I have not experienced any problem with this approach for two reasons:

1) I always package my applications as EARs and run them in a J2EE 1.4
compliant container.  This makes all applications independent from each
other and the logging classes loaded into memory also independent from
one app to the next.   So each could take over the root logger and it
would not affect the container or other apps.  Note:  This was not
possible in jBoss prior to 4.0.2 due to some sort of Tomcat bug that
they inherited (check their release notes and forums for details).

2) By convention we always name log4j.xml and log files with the name
of the app.  For example, myappLog4j.xml and myapp.log.

My apologies for the late reply... I've been away from this thread for
almost 3 weeks.

Bruno Melloni

Bruno Melloni
Director of Software Architecture
Akuratus Corporation
1333 N. Stemmons Fwy, Suite 110
Dallas, Texas 75207
Phone: 469.227.0920
Fax: 469.227.0967
bruno.melloni@akuratus.com
www.akuratus.com

>>> kaufman@creditex.com 6/21/2005 4:38:55 PM >>>
Can't agree anymore on this.  I have seen a system in which we have
many different jars that have their own log4j.properties.  If you don't
put your own explicit log4j.properties in classpath or WEB-INF/classes,
expect to see weird logging layouts at strange places.  Cheers.

-----Original Message-----
From: Javier Gonzalez [mailto:jagonzal@gmail.com] 
Sent: Tuesday, June 21, 2005 5:24 PM
To: Log4J Users List
Subject: Spam:Re: Reading config.xml from jarfile


On 6/21/05, Bruno Melloni <Br...@akuratus.com> wrote:
> But I'd like to suggest that you don't "just" put the XML config
file
> in the webapp.  You really want to do both.  A few days ago someone
> mentioned the name of an environment variable that if passed at app
> server startup (with -D... option) it would say where to pick up the
> log4j file.

But you must be careful with this - sometimes, you get somebody else's
jar with a log4j.properties buried inside it, and it decides it wants
the root logger in DEBUG level, or your Layour isn't as nice as the
one defined in said log4j.properties file. Or, God forbid, you get a
jar that gets into its head the idea of setting the
log4j.configuration property to its own secret log4j file. Now, you
get your tomcat running, and it logs fine. Reload your context and all
your logger configurations are gone.

If your logs start disappearing or formatting wrong after a context
reload, check your jars for a rogue log4j.properties, or the
log4j.configuration system variable. Might save you the time I lost
finding it out :)

-- 
Javier Gonzalez Nicolini

---------------------------------------------------------------------
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