RE: Reposting of Log4J Question
By way of an answer to the original question of how to separate the logging of an application on JBoss, the only satisfactory solution I've found has been to stop using the ConsoleAppender and stick with a RotatingFileAppender. All my applications loggers use this appender, and their additivity is set to false. This way, I get a file (or group of files) per application, in a format that suits me. It's low tech but it's portable and it works. Regards, Brendan. -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: 26 February 2003 15:11 To: Log4J Users List Subject: Re: Reposting of Log4J Question Hi Naresh, No, I mean one repository selector per JVM. Actually, this is sort of per ClassLoader if you look at the case of webapps where the classloading behavior is different than normal. Webapps load classes, preferentially, from the WebappClassLoader before looking to its parent classloader(s) so if Log4j is stored in WEB-INF/lib of each app, Log4j has multiple unique logging environments in a single JVM. However, if normal classloading behavior is assumed, then it is once per JVM. Either way, Log4j can have only one selector at a time in any single unique logging environment. It is the repository selector that maintains the separation of repositories. Any individual repository selector must override the getLoggerRepository() method. Log4j will call that method to get the logger repository for an application. If the selector is being smart and storing some information which identifies certain applications, it can return a unique logger repository per application. That is what the ContextClassLoaderSelector does. It stores a map of logger repositories and keys each logger repository by the context classloader (the WebappClassLoader unique to each webapp). So when Log4j asks for the logger repository in order to log for the app, the selector will only return the logger repository keyed for that application. Make sure you don't confuse the LoggerRepositorySelector with the LoggerRepository. Only one of the former can be set at any one time (which we guard). There can be infinite of the latter. Does that make more sense? Jake At 08:13 PM 2/25/2003 -0800, you wrote: Hi Jacob, Iam attempting to incorporate similar custom repository selector approach. You mentioned Note that Log4j will only use *ONE* custom repository selector. Did u mean one custom repository selector per app? If the answer is Yes, than my confusion is, Since LogManager has one private member variable of type repository selector and we initialize that to a custom repository by following Object guard = new Object(); LogManager.setRepositorySelector(new CusRepository(contextName), guard); and if log4j is loaded only one time by the parent classloader, how does logmanager maintain reference of every application's CusRepositry ? --- Jacob Kjome [EMAIL PROTECTED] wrote: Hello James, The functionality you are looking for is to be able to log within unique logger repositories using a custom logger repository selector. I have implemented such a selector (and a servlet context listener which configures log4j to use it at app/server startup) which keys logger repositories on the current classloader. Ceki has written about a repository selector which would use JNDI to key logger repositories. Now, since you are using JBoss and they have their single classloader concept (which, admittedly, I'm not so familiar with) I'm not sure the repository selector that I wrote will work for you. It certainly works in an environment where each webapp has its own unique classloader. This still might be true for JBoss, but I'm not positive. To check out the repository selector I wrote, look here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log 4j/selector/ContextClassLoaderSelector.java?rev=1.3content-type=text/vnd.vi ewcvs-markup See the servlet context listener which initializes Log4j to use this custom selector here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log 4j/servlet/InitContextListener.java?rev=1.2content-type=text/vnd.viewcvs-ma rkup Note that Log4j will only use *ONE* custom repository selector. Once one is installed, the only way to change it to re-install the selector along with the original guard object which is used to protect the selector from being changed by a process not meant to do so. So, unless you store the guard, you can pretty much assume that this is a one-shot thing. As such, ideally, the container should be responsible for installing the selector. My servlet context listener allows for any particular webapp to install the selector if one isn't already installed. If one is, the installation will fail and the exception hidden. In this situation, it is assumed that whatever process did the install knew what
RE: Reposting of Log4J Question
James, I tried that too - having separate loggers and a separate Appender. But even then I encountered the problem you mentioned: my output was appended onto the end of JBoss' logs format. Could you (offline perhaps, to spare the list a repost) send me an example config file? Thanks, Brendan. Brendan Lawlor Spokesoft Business Components Ltd. T: +353 21 2307051 The NSC-Campus F: +353 21 2307033 Loughmahon Technology Park M: +353 87 9370271 Cork www.spokesoft.com Ireland -Original Message- From: Corbin, James [mailto:[EMAIL PROTECTED] Sent: 27 February 2003 15:42 To: Log4J Users List Subject: RE: Reposting of Log4J Question Brendan, Per another post, I defined a different logger in my local config and it doesn't conflict with the JBOSS logging. For example, I defined MyConsoleAppender and MyFileAppender (RollingFileAppender) Then defined log4j.logger.com.company.=DEBUG, MyConsoleAppender, MyFileAppender Hope this helps. J.D. -Original Message- From: Brendan Lawlor [mailto:[EMAIL PROTECTED] Sent: Thursday, February 27, 2003 4:15 AM To: Log4J Users List Subject: RE: Reposting of Log4J Question By way of an answer to the original question of how to separate the logging of an application on JBoss, the only satisfactory solution I've found has been to stop using the ConsoleAppender and stick with a RotatingFileAppender. All my applications loggers use this appender, and their additivity is set to false. This way, I get a file (or group of files) per application, in a format that suits me. It's low tech but it's portable and it works. Regards, Brendan. -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: 26 February 2003 15:11 To: Log4J Users List Subject: Re: Reposting of Log4J Question Hi Naresh, No, I mean one repository selector per JVM. Actually, this is sort of per ClassLoader if you look at the case of webapps where the classloading behavior is different than normal. Webapps load classes, preferentially, from the WebappClassLoader before looking to its parent classloader(s) so if Log4j is stored in WEB-INF/lib of each app, Log4j has multiple unique logging environments in a single JVM. However, if normal classloading behavior is assumed, then it is once per JVM. Either way, Log4j can have only one selector at a time in any single unique logging environment. It is the repository selector that maintains the separation of repositories. Any individual repository selector must override the getLoggerRepository() method. Log4j will call that method to get the logger repository for an application. If the selector is being smart and storing some information which identifies certain applications, it can return a unique logger repository per application. That is what the ContextClassLoaderSelector does. It stores a map of logger repositories and keys each logger repository by the context classloader (the WebappClassLoader unique to each webapp). So when Log4j asks for the logger repository in order to log for the app, the selector will only return the logger repository keyed for that application. Make sure you don't confuse the LoggerRepositorySelector with the LoggerRepository. Only one of the former can be set at any one time (which we guard). There can be infinite of the latter. Does that make more sense? Jake At 08:13 PM 2/25/2003 -0800, you wrote: Hi Jacob, Iam attempting to incorporate similar custom repository selector approach. You mentioned Note that Log4j will only use *ONE* custom repository selector. Did u mean one custom repository selector per app? If the answer is Yes, than my confusion is, Since LogManager has one private member variable of type repository selector and we initialize that to a custom repository by following Object guard = new Object(); LogManager.setRepositorySelector(new CusRepository(contextName), guard); and if log4j is loaded only one time by the parent classloader, how does logmanager maintain reference of every application's CusRepositry ? --- Jacob Kjome [EMAIL PROTECTED] wrote: Hello James, The functionality you are looking for is to be able to log within unique logger repositories using a custom logger repository selector. I have implemented such a selector (and a servlet context listener which configures log4j to use it at app/server startup) which keys logger repositories on the current classloader. Ceki has written about a repository selector which would use JNDI to key logger repositories. Now, since you are using JBoss and they have their single classloader concept (which, admittedly, I'm not so familiar with) I'm not sure the repository selector that I wrote will work for you. It certainly works in an environment where each webapp has its own unique classloader. This still might be true for JBoss, but I'm not positive. To check out
Re: Reposting of Log4J Question
Hello James, The functionality you are looking for is to be able to log within unique logger repositories using a custom logger repository selector. I have implemented such a selector (and a servlet context listener which configures log4j to use it at app/server startup) which keys logger repositories on the current classloader. Ceki has written about a repository selector which would use JNDI to key logger repositories. Now, since you are using JBoss and they have their single classloader concept (which, admittedly, I'm not so familiar with) I'm not sure the repository selector that I wrote will work for you. It certainly works in an environment where each webapp has its own unique classloader. This still might be true for JBoss, but I'm not positive. To check out the repository selector I wrote, look here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/ContextClassLoaderSelector.java?rev=1.3content-type=text/vnd.viewcvs-markup See the servlet context listener which initializes Log4j to use this custom selector here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/InitContextListener.java?rev=1.2content-type=text/vnd.viewcvs-markup Note that Log4j will only use *ONE* custom repository selector. Once one is installed, the only way to change it to re-install the selector along with the original guard object which is used to protect the selector from being changed by a process not meant to do so. So, unless you store the guard, you can pretty much assume that this is a one-shot thing. As such, ideally, the container should be responsible for installing the selector. My servlet context listener allows for any particular webapp to install the selector if one isn't already installed. If one is, the installation will fail and the exception hidden. In this situation, it is assumed that whatever process did the install knew what it was doing and the app will just have to live with the decision. For sure, read Ceki's article about custom selectors and pay attention to the JNDI selector discussion: http://qos.ch/logging/sc.html Note, if you implement a JNDI selector that works for you, it would be great if you could contribute that back to the Log4j-sandbox project! Jake Tuesday, February 25, 2003, 1:48:51 PM, you wrote: CJ An answer to this question/problem is very important to my project group so CJ please take time to read and understand it. Thanks. I struggled with CJ posting this to a JBOSS group but decided it was more of an issue with the CJ use of Log4J and not so much how JBOSS was using it. CJ I am using JBOSS and am attempting to define application independent logging CJ using Log4J. CJ JBOSS uses Log4J for their logging as well, which is where my problems CJ begin. CJ If I use the PropertyConfigurator to configure log4J using an application CJ specific config file. Its settings conflict with the JBOSS logging. My CJ first attempt was defining the root and file appenders for the root logger CJ which is probably what was throwing the Log4J logging into a loop. CJ My solution was to define a category and log to that vs. getting the logger CJ and logging to it. CJ The results were encouraging but problematic as well. My error, debug, info CJ messages are showing up in the JBOSS console log just fine, but are appended CJ to an [INFO] message from the JBOSS (log4j) logging. So it appears that CJ every message logged to my category is getting appended to a JBOSS log CJ message (in this case INFO priority) before being logged to the console or CJ file. CJ How can I define my application specific logging so it can coexist with the CJ logging configuration defined by the app server which uses log4J but be CJ independent. I do not want to have to modify the log4J configuration that CJ is setup by the JBOSS server implementation. I want to be able to configure CJ my own configuration file, load it with a console and file appenders that CJ coexist with the ones in the JBOSS specific log4J configuration but do not CJ conflict with the root ones defined. HOW? CJ Below is a snapshot of my application log4j configuration file that I am CJ loading. The JBOSS log4j configuration appears to define a console and file CJ appender for the root logger. This configuration works with the caveat that CJ any logging to this category gets appended to the JBOSS log text before CJ being displayed to the console or log file. CJ ## The server.log file appender for LightSpeed CJ log4j.category.LightSpeed=, LightSpeed_Console, LightSpeed_Default CJ log4j.appender.LightSpeed_Default=org.apache.log4j.RollingFileAppender CJ log4j.appender.LightSpeed_Default.File=server.log CJ log4j.appender.LightSpeed_Default.MaxFileSize=500KB CJ log4j.appender.LightSpeed_Default.MaxBackupIndex=1 CJ log4j.appender.LightSpeed_Default.layout=org.apache.log4j.PatternLayout CJ
Re: Reposting of Log4J Question
The problem w/ jBoss is that they 'get there first'.. in that they use log4j for their own internal logging log4j.jar exists in the Containers CLASSPATH and the first time an internal logging statement is hit log4j initializes itself w/ the log4j.xml configuration file located (by default) in $JBOSS_HOME/server/config, which is in the containers CLASSPATH. If you load a custom ContextRespositorySelector within an Applications space, I suspect the default ClassLoader behavior will push it up the chain and you end up effecting the whole jBoss appserver, not just the webapp in question (I think... I played around w/ resolving this issue in the past, and seem to recall that being the problem...) I seem to recall conversations on jBoss forums/listservs that would allow for a Custom CRS to be loaded by the container, so you might check the archives on jboss.org. -don At 02:44 PM 2/25/2003 -0600, Jacob Kjome wrote: Hello James, The functionality you are looking for is to be able to log within unique logger repositories using a custom logger repository selector. I have implemented such a selector (and a servlet context listener which configures log4j to use it at app/server startup) which keys logger repositories on the current classloader. Ceki has written about a repository selector which would use JNDI to key logger repositories. Now, since you are using JBoss and they have their single classloader concept (which, admittedly, I'm not so familiar with) I'm not sure the repository selector that I wrote will work for you. It certainly works in an environment where each webapp has its own unique classloader. This still might be true for JBoss, but I'm not positive. To check out the repository selector I wrote, look here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/ContextClassLoaderSelector.java?rev=1.3content-type=text/vnd.viewcvs-markup See the servlet context listener which initializes Log4j to use this custom selector here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/InitContextListener.java?rev=1.2content-type=text/vnd.viewcvs-markup Note that Log4j will only use *ONE* custom repository selector. Once one is installed, the only way to change it to re-install the selector along with the original guard object which is used to protect the selector from being changed by a process not meant to do so. So, unless you store the guard, you can pretty much assume that this is a one-shot thing. As such, ideally, the container should be responsible for installing the selector. My servlet context listener allows for any particular webapp to install the selector if one isn't already installed. If one is, the installation will fail and the exception hidden. In this situation, it is assumed that whatever process did the install knew what it was doing and the app will just have to live with the decision. For sure, read Ceki's article about custom selectors and pay attention to the JNDI selector discussion: http://qos.ch/logging/sc.html Note, if you implement a JNDI selector that works for you, it would be great if you could contribute that back to the Log4j-sandbox project! Jake Tuesday, February 25, 2003, 1:48:51 PM, you wrote: CJ An answer to this question/problem is very important to my project group so CJ please take time to read and understand it. Thanks. I struggled with CJ posting this to a JBOSS group but decided it was more of an issue with the CJ use of Log4J and not so much how JBOSS was using it. CJ I am using JBOSS and am attempting to define application independent logging CJ using Log4J. CJ JBOSS uses Log4J for their logging as well, which is where my problems CJ begin. CJ If I use the PropertyConfigurator to configure log4J using an application CJ specific config file. Its settings conflict with the JBOSS logging. My CJ first attempt was defining the root and file appenders for the root logger CJ which is probably what was throwing the Log4J logging into a loop. CJ My solution was to define a category and log to that vs. getting the logger CJ and logging to it. CJ The results were encouraging but problematic as well. My error, debug, info CJ messages are showing up in the JBOSS console log just fine, but are appended CJ to an [INFO] message from the JBOSS (log4j) logging. So it appears that CJ every message logged to my category is getting appended to a JBOSS log CJ message (in this case INFO priority) before being logged to the console or CJ file. CJ How can I define my application specific logging so it can coexist with the CJ logging configuration defined by the app server which uses log4J but be CJ independent. I do not want to have to modify the log4J configuration that CJ is setup by the JBOSS server implementation. I want to be able to configure CJ my own configuration file, load it with a console and file appenders that CJ coexist with the ones in the JBOSS
RE: Reposting of Log4J Question
Thanks Don. I think what you describe is happening. I will search the forums further. So, what was your solution? It sounds like the custom ContextRepositorySelector did not work for you. I may have misinterpreted your email. Thanks, J.D. -Original Message- From: donald larmee [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 4:40 PM To: Log4J Users List; Log4J Users List Subject: Re: Reposting of Log4J Question The problem w/ jBoss is that they 'get there first'.. in that they use log4j for their own internal logging log4j.jar exists in the Containers CLASSPATH and the first time an internal logging statement is hit log4j initializes itself w/ the log4j.xml configuration file located (by default) in $JBOSS_HOME/server/config, which is in the containers CLASSPATH. If you load a custom ContextRespositorySelector within an Applications space, I suspect the default ClassLoader behavior will push it up the chain and you end up effecting the whole jBoss appserver, not just the webapp in question (I think... I played around w/ resolving this issue in the past, and seem to recall that being the problem...) I seem to recall conversations on jBoss forums/listservs that would allow for a Custom CRS to be loaded by the container, so you might check the archives on jboss.org. -don At 02:44 PM 2/25/2003 -0600, Jacob Kjome wrote: Hello James, The functionality you are looking for is to be able to log within unique logger repositories using a custom logger repository selector. I have implemented such a selector (and a servlet context listener which configures log4j to use it at app/server startup) which keys logger repositories on the current classloader. Ceki has written about a repository selector which would use JNDI to key logger repositories. Now, since you are using JBoss and they have their single classloader concept (which, admittedly, I'm not so familiar with) I'm not sure the repository selector that I wrote will work for you. It certainly works in an environment where each webapp has its own unique classloader. This still might be true for JBoss, but I'm not positive. To check out the repository selector I wrote, look here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log 4j/selector/ContextClassLoaderSelector.java?rev=1.3content-type=text/vnd.vi ewcvs-markup See the servlet context listener which initializes Log4j to use this custom selector here: http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log 4j/servlet/InitContextListener.java?rev=1.2content-type=text/vnd.viewcvs-ma rkup Note that Log4j will only use *ONE* custom repository selector. Once one is installed, the only way to change it to re-install the selector along with the original guard object which is used to protect the selector from being changed by a process not meant to do so. So, unless you store the guard, you can pretty much assume that this is a one-shot thing. As such, ideally, the container should be responsible for installing the selector. My servlet context listener allows for any particular webapp to install the selector if one isn't already installed. If one is, the installation will fail and the exception hidden. In this situation, it is assumed that whatever process did the install knew what it was doing and the app will just have to live with the decision. For sure, read Ceki's article about custom selectors and pay attention to the JNDI selector discussion: http://qos.ch/logging/sc.html Note, if you implement a JNDI selector that works for you, it would be great if you could contribute that back to the Log4j-sandbox project! Jake Tuesday, February 25, 2003, 1:48:51 PM, you wrote: CJ An answer to this question/problem is very important to my project group so CJ please take time to read and understand it. Thanks. I struggled with CJ posting this to a JBOSS group but decided it was more of an issue with the CJ use of Log4J and not so much how JBOSS was using it. CJ I am using JBOSS and am attempting to define application independent logging CJ using Log4J. CJ JBOSS uses Log4J for their logging as well, which is where my problems CJ begin. CJ If I use the PropertyConfigurator to configure log4J using an application CJ specific config file. Its settings conflict with the JBOSS logging. My CJ first attempt was defining the root and file appenders for the root logger CJ which is probably what was throwing the Log4J logging into a loop. CJ My solution was to define a category and log to that vs. getting the logger CJ and logging to it. CJ The results were encouraging but problematic as well. My error, debug, info CJ messages are showing up in the JBOSS console log just fine, but are appended CJ to an [INFO] message from the JBOSS (log4j) logging. So it appears that CJ every message logged to my category is getting appended to a JBOSS log CJ message (in this case INFO priority) before being logged
