Quoting Jacob Kjome:
"However, each time you perform a configuration with Log4j, the
previous one will be wiped out; within the same logger repository (in the
same class loader, of course), that is."

Are you sure that the existing set-up gets wiped? I set up Log4J in an
App-server using PropertyConfigurator.configure(String) and in my situation
there are some other "legacy" EJBs deployed that may heve set-up Log4j
already and I find I need to call LogManager.resetConfiguration() if I want
to clear the existing set-up.

Cheers
Adrian

-----Original Message-----
From: Jacob Kjome [mailto:[EMAIL PROTECTED]
Sent: 24 November 2003 04:03
To: Log4J Users List
Subject: Re: Multiple Log4j configuration files in EJB Container (one
jvm)


At 04:02 PM 11/23/2003 -0500, you wrote:
>Hi,
>I don't know whether anyone has answered this already (I could not
>find).  I am using Websphere application server 5.0 (EJB Container).  I am
>using log4j for the logging in my ejb's.  I have created a start up bean
>(special case of a stateless session bean that is called first by the
>container) to configure the log4j (which writes all the logs to a JMS
>topic) and I have a MDB that reads from the topic and writes to flat files
>(there I read another the log4j configuration file). since all these beans
>are deployed in the same container and loaded by the same class loader, I
>was wondering would there be any collisions between these two log4j
>configuration files?

You are configuring things explicitly and not counting on
auto-configuration.  As such, the various properties files shouldn't
"collide".  However, each time you perform a configuration with Log4j, the
previous one will be wiped out; within the same logger repository (in the
same class loader, of course), that is.

>wondering anyone come across this scenario?

If you are needing configuration for two different components and want to
different properties defined for each within the same class loader, then
you will have to use a repository selector so that they don't trample on
each other.

>thanks,
>Srini

Jake


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


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

Reply via email to