Reposting of Log4J Question
An answer to this question/problem is very important to my project group so
please take time to read and understand it. Thanks. I struggled with
posting this to a JBOSS group but decided it was more of an issue with the
use of Log4J and not so much how JBOSS was using it.
I am using JBOSS and am attempting to define application independent logging
using Log4J.
JBOSS uses Log4J for their logging as well, which is where my problems
begin.
If I use the PropertyConfigurator to configure log4J using an application
specific config file. Its settings conflict with the JBOSS logging. My
first attempt was defining the root and file appenders for the root logger
which is probably what was throwing the Log4J logging into a loop.
My solution was to define a category and log to that vs. getting the logger
and logging to it.
The results were encouraging but problematic as well. My error, debug, info
messages are showing up in the JBOSS console log just fine, but are appended
to an [INFO] message from the JBOSS (log4j) logging. So it appears that
every message logged to my category is getting appended to a JBOSS log
message (in this case INFO priority) before being logged to the console or
file.
How can I define my application specific logging so it can coexist with the
logging configuration defined by the app server which uses log4J but be
independent. I do not want to have to modify the log4J configuration that
is setup by the JBOSS server implementation. I want to be able to configure
my own configuration file, load it with a console and file appenders that
coexist with the ones in the JBOSS specific log4J configuration but do not
conflict with the root ones defined. HOW?
Below is a snapshot of my application log4j configuration file that I am
loading. The JBOSS log4j configuration appears to define a console and file
appender for the root logger. This configuration works with the caveat that
any logging to this category gets appended to the JBOSS log text before
being displayed to the console or log file.
## The server.log file appender for LightSpeed
log4j.category.LightSpeed=, LightSpeed_Console, LightSpeed_Default
log4j.appender.LightSpeed_Default=org.apache.log4j.RollingFileAppender
log4j.appender.LightSpeed_Default.File=server.log
log4j.appender.LightSpeed_Default.MaxFileSize=500KB
log4j.appender.LightSpeed_Default.MaxBackupIndex=1
log4j.appender.LightSpeed_Default.layout=org.apache.log4j.PatternLayout
#log4j.appender.LightSpeed_Default.layout.ConversionPattern=%d %-5p [%t]
%-17c{2} (%13F:%L) %3x - %m\n
#log4j.appender.LightSpeed_Default.layout.ConversionPattern=[%d{ABSOLUTE},%c
{1}] %m%n
log4j.appender.LightSpeed_Default.layout.ConversionPattern=%d{ABSOLUTE},%-17
c [%-5p] - %m%n
#log4j.additivity.LightSpeed=false
log4j.appender.LightSpeed_Console=org.apache.log4j.ConsoleAppender
log4j.appender.LightSpeed_Console.layout=org.apache.log4j.PatternLayout
log4j.appender.LightSpeed_Console.layout.ConversionPattern=%d{ABSOLUTE},%-17
c [%-5p] - %m%n
Thanks,
J.D.
This electronic message transmission contains information from the Company that may be
proprietary, confidential and/or privileged.
The information is intended only for the use of the individual(s) or entity named
above. If you are not the intended recipient, be
aware that any disclosure, copying or distribution or use of the contents of this
information is prohibited. If you have received
this electronic transmission in error, please notify the sender immediately by
replying to the address listed in the From: field.
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
Writing Custom Logger by extending the Logger class
Hi,
I am trying to write my customLogger by extending the
java.util.logging.Logger class.
I want to know is this the right approach ,the way I am doing.
class TSPPXMLLogger extends Logger {
private static TSPPXMLLogger logger = null;
public TSPPXMLLogger(String name,String localization){
super(name,localization);
}
public static Logger getLogger(String name){
if(logger == null){
logger = new TSPPXMLLogger(name,null);
return logger;
}
else
return logger;
//do some impl here..should I ?
}
public void logError(Level level,String message){
super.log(level,message);
}
public void logFileError(Level level,String message,String stackTrace){
//do some impl here.
TSPPLoggerHelper tsppLoggerHelper = new TSPPLoggerHelper();
tsppLoggerHelper.setStackTrace(stackTrace);
super.log(level,message,tsppLoggerHelper);
}
public void addHandler(Handler handler){
super.addHandler(handler);
//Client Code..
private static TSPPXMLLogger logger = (TSPPXMLLogger)
TSPPXMLLogger.getLogger(TSPP);
private static TSPPXMLLogger testtsppXMLLogger =
(TSPPXMLLogger)TSPPXMLLogger.getLogger(aaaTSPP);
logger.logFileError(,,);
Both give me same instance(because of the way I implemented), Is that
ok.?
Will it result in any kind of threading issues?
Any kind of pointers will be appreciated.
Regards,
Anoop Singh
