logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bender Heri <hben...@ergonomics.ch>
Subject AW: Logging done in the wrong files
Date Wed, 16 Sep 2009 13:54:50 GMT
First: I do not know much about Jboss, especially not about the ordering of the classloader
If your jar file is shared among all applications then the first initialized application wins
(means executes as first the static code). You have to deploy the class with the static code
into each application and ensure that Jboss loads child first (means first the application
specific classloader searches for the class in the application class path, and only if not
found the parent classloader searches in the global class path).

Second: Although you call your logger wrapper "LogManager" it does not replace the built in
LogManager of log4j. The log4j LogManager is still instantiated at the first time you call
Logger.getLogger() or any configuration method of LogManager. In order to specify your own
RepositorySelector initialize it somewhere at the start up of your application and call (log4j).LogManager.setRepositorySelector(
myRepSel ). 

You have two ways to go: 
Either you get the classloading issues to work (have absolutely separate log4j universes).
This includes deploying log4j.jar in each application along with the appropriate config file.
You write your own RepositorySelector, initialize and use it (and the log4j.jar) in the common
scope. Going this way you have to find out a way how the RepositorySelector can distinguish
the application context and provide the correct logger (each application has ist own loggers
and appenders). The configuration is although a bit tricky: The common aspects (levels, logger-appender
associations, layout, filters, etc.) can be done by a global config file, but the file name
of a file appender must be provided at runtime depending on the application context. 
Choosing the second way there are other topics to be considered: Only classes which are unique
to an application can have a static member for the logger instance. Classes shared among the
applications (assuming an instance of this class is only used in one application) must have
NON-STATIC Logger members. And helper classes with only static methods must call Logger.getLogger()
in each method call again.


-----Urspr√ľngliche Nachricht-----
Von: S.Kannan [mailto:techy_kans@yahoo.co.in] 
Gesendet: Mittwoch, 16. September 2009 14:15
An: log4j-user@logging.apache.org
Betreff: RE: Logging done in the wrong files

Thanks Brown for the reply.

The following was the reply given by Bender Heri Your problem is a classloader issue. Keep
in mind that the Logger-Universe which you initialize within your static method is globally
the same within the same classloader. Annother classloader would initialize another logger-universe.
You have to elaborate which class is loaded by which classloader. This depends on the application
server you use, its configuration and your deployment. 
Search the archives for "MultiFileAppender" and "RepositorySelector". There are plenty of
ideas how to separate log files depending on the context. 

The jboss app server gives an option like
 <!-- A flag indicating if ear deployments should have their own scoped
      class loader to isolate their classes from other deployments.
      <attribute name="Isolated">true</attribute>

which we have set as true. Thus different applications have different class loaders and from
the reply of Bender i could understand that there are different logger-universe defined. Consider
that  The LogManager which i have mentioned earlier is in a jar file. This jar file is shared
across all the EAR files. The log4j.properties file alone differs for each module. I could
not figure out on how to use the RepositorySelector when my LogManager does not extend the
log4j's LogManager . Any thoughts?
View this message in context: http://www.nabble.com/Logging-done-in-the-wrong-files-tp25411329p25471153.html
Sent from the Log4j - Users mailing list archive at Nabble.com.

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

View raw message