First: I do not know much about Jboss, especially not about the ordering of the classloader preferences. 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. Or: 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. Heri -----Ursprüngliche Nachricht----- Von: S.Kannan [mailto:[email protected]] Gesendet: Mittwoch, 16. September 2009 14:15 An: [email protected] 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: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
