Hi,
It sounds like some of your problems come from relying on the default
log4j startup configuration, where it looks for log4j.properties on the
classpath.  A possible alternative, the one we use, is to write a
startup servlet that loads on server startup and does the log4j
configuration for you.  

You could then further add a GUI of sorts to that servlet for runtime
changes of the logging system.  Or a simple "reload from this URL"-type
function where you specify the URL to a new configuration file you just
edited.

Yoav Shapira
Millennium ChemInformatics


>-----Original Message-----
>From: Lu, David [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, July 24, 2002 2:22 PM
>To: [EMAIL PROTECTED]
>Subject: large scale log4j configuration
>
>Hi everyone,
>
>Where do most people put their configuration files in a multi-ear,
multi-
>war
>and multi-jar environment?
>I see several cons of putting each configuration file within each jar
(as
>opposed to the system cp).
>
>1. For my webapp, I have a security.jar file which uses log4j.  This
>security.jar is in the WEB-INF/lib directory of my webapp.
>When the application is deployed, log4j complains that there are no
>appenders defined for a logger used in security.jar.
>However, if I place the configuration file in the system CP, everything
is
>fine.
>
>2. If the configuration file is placed inside each application's jar,
>doesn't this make for management headaches, say, if I want to do a
change
>configuration on the fly but don't have access into each jar file to
get at
>the configuration file?
>
>Thanks for reading.
>
>David
>
>
>**********************************************************************
>This message, including any attachments, contains confidential
information
>intended for a specific individual and purpose, and is protected by
law.
>If you are not the intended recipient, please contact sender
immediately by
>reply e-mail and destroy all copies.  You are hereby notified that any
>disclosure, copying, or distribution of this message, or the taking of
any
>action based on it, is strictly prohibited.
>TIAA-CREF
>**********************************************************************
>
>--
>To unsubscribe, e-mail:   <mailto:log4j-user-
>[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:log4j-user-
>[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to