RE: additivity attribute does not work for user-defined logger but works for root logger.
Thanks a lot, it makes perfect sense. I think that i use MDC or NDC(the code works only on server side). In my code I am able to name a thread an reuse it, so this gives additional solution. Bender Heri wrote: OK, in the following I denote foo.bar.XY as AppA and com.create.CR as AppB and the test.bulk.ZY as UtilityC. Possible solutions: 1. If the UtilityC is instantiated separatly by AppA and AppB (two instances) you are perfectly done by configuring each instance with the desired logger: Config: appender A appender B Logger AppA with appender A Logger AppB with appender B Logger AppA.UtilityC with appender A Logger AppB.UtilityC with appender B Code: Use the suggestion of jake Kjome from today morning. The constructor of SQLStatements wich receives the classname of the calling class must then expand the logger name: receivedClassName + . + this.getClass.getSimpleName(). With this logger name you retrieve the logger from the repository. If AppA had called the constructor, you get the Logger AppA.UtilityC, and so on. 2. Supply the desired logger on each call to the UtilityC class: public static void UtilityC.doSomething( Logger aLoggerToUse ); {...} Drawback: The location info in the log statements would be the location of the call to doSomething(). You can avoid this by using in the UtilityC the generic call of Logger log(): aLoggerToUse.log ( this.getClass.getName(), Level.DEBUG, logMsg, aThrowable ) 3. Since the AppA and AppB run in different threads you could use a MDC value within UtilityC in order to distinguish the loggers. Maybe in combination with a own Repository-Selector which relies on the actual values in MDC. Search the archive, this was discussed a lot, and I supplied whole examples. I hope you got the hint in which direction you should think. Otherwise ask again. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2008 5:23 PM To: log4j-user@logging.apache.org Subject: RE: additivity attribute does not work for user-defined logger but works for root logger. Yes, it is a typo. Should be: I need two full log files for foo.bar.XY and com.create.CR with all the logs information from test.bulk.ZY Yes the foo.bar.XY and com.create.CR are run in different threads. I want two logs files - one for foo.bar.XY and the second one for com.create.CR. All of them should have all the calls made in test.bulk.ZY (treat it as utility class) Do you want the logs of test.bulk.ZY which were called by foo.bar.XY in the log file of foo.bar.XY and the logs of test.bulk.ZY which were called by com.create.CR in the log file of com.create.CR? Yes. the foo.bar.XY and com.create.CR has some logging messages as well that needs to go to the right log file. Thanks for helping me with it. M. Bender Heri wrote: Questions see inline. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2008 3:24 PM To: log4j-user@logging.apache.org Subject: RE: additivity attribute does not work for user-defined logger but works for root logger. But in my case I hit slightly different problem. The class foo.bar.XY calls lets say test.bulk.ZY and the class com.create.CR calls test.bulk.ZY as well. Do this two classes (foo.bar.XY and com.create.CR) run in different threads? Or is it the same thread? - Influences possible solutions! I need two full log files for foo.bar.XY and test.bulk.ZY with all the logs information from test.bulk.ZY. Does not make any sense for me. Is it a typo? (test.bulk.ZY in first line should be com.create.CR?). If so, then next question: Do you want the logs of test.bulk.ZY which were called by foo.bar.XY in the log file of foo.bar and the logs of test.bulk.ZY which were called by com.create.CR in the log file of com.create.CR? Otherwise you have to explain more detailled which log calls you want to appear in which appender. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work -for-user-defined-logger-but-works-for-root-logger.-tp18259092 p18319243.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] -- View this message in context:
Re: additivity attribute does not work for user-defined logger but works for root logger.
Thanks. I like your idea with the constructor but I call also the code that I do not have an acces and I cannot modify, so I needed to look for something different. I have decided to use apache-log4j-extras-1.0.jar and use filters(org.apache.log4j.filter.ExpressionFilter). In each specific class I give an unique name for the thread associated with the tool. Then my log4j.xml looks like: log4j:configuration debug=true xmlns:log4j=http://jakarta.apache.org/log4j/; appender name=addQuestionSequenceOrder class=org.apache.log4j.RollingFileAppender layout class=org.apache.log4j.PatternLayout /layout filter class=org.apache.log4j.filter.ExpressionFilter / /filter filter class=org.apache.log4j.filter.DenyAllFilter/ /appender appender name=taskRedirection class=org.apache.log4j.RollingFileAppender layout class=org.apache.log4j.PatternLayout /layout filter class=org.apache.log4j.filter.ExpressionFilter /filter filter class=org.apache.log4j.filter.DenyAllFilter/ /appender root level value=debug/ appender-ref ref=addQuestionSequenceOrder/ appender-ref ref=taskRedirection/ /root /log4j:configuration I hope it would help anybody else. NCP instead of THREAD could be used as well, but it required additional changes to the code. M. Jacob Kjome wrote: Camer38 wrote: I have two Java classes that used log4j. curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter and curam.tools.upgradehelper.taskredirection.TaskRedirectionConverter Both classes from above uses different class: curam.tools.upgradehelper.util.SQLStatements where a logger in each of the class with defined in following pattern: private static final Logger log = Logger.getLogger(NameOfTheClass.class); Next I have defined log4j.xml. I want to have a full log file in two separate files for both classes. curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in QuestionSequenceOrderConverterTool.log curam.tools.upgradehelper.taskredirection.TaskRedirectionConverter in TaskRedirectionConverterTool.log I did a following: I have not defined root at all. My assumption was that if I run one of the class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter I would got all the logs from that class and all the classes used internally by curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in the addQuestionSequenceOrderTool.log. That's simply not the way Log4j works. Logger naming is hierarchical, and though this does not have to be packaged-based, that's the traditional usage. Instead I got an log4j warning: log4j:WARN No appenders could be found for logger (curam.tools.upgradehelper.util.SQLStatements). ...because curam.tools.upgradehelper.util.SQLStatements is not part of the naming hierarchy of either of the defined loggers. This is why you usually define the ROOT logger as a catch-all. What is the meaning of the attribute additivity for each logger? Why don't I get all the logs in one file? During my testing I have defined a root logger as well, but it does not do what I want. All the expected lines are present in both files but the files are populated with the log from the same class. root level value=info/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root As I said previously, using package names is the traditional usage, but it's not the only way to name loggers. You can use any arbitrary naming scheme. Of course, the problem you are running into here is that you want one utility class's logging to go to one of two separate files depending on which class used the utility. That's only possible if you design the utility class to change it's logging name each time it is used. You'll have do add a constructor that takes a logger name, such as... public SQLStatements(String loggerName) {...} And then each time you use this helper class, pass in the logger name to use. For instance... public class QuestionSequenceOrderConverter { public void doSomething() { SQLStatements ss = new SQLStatements(this.getClass().getName()); } } The other way to do this is to use something like SLF4J/Logback's Markers to associate distinct loggers in a user-defined way. Log4j 1.3 started with this, but it was abandoned. I believe there's work in progress for something like this in the Log4j extras or companions, though i can't remember what it's called, offhand? I use log4j-1.2.15.jar Could anybody help me with defining a correct log4j.xml file? You're looking for additivity=false, not
RE: additivity attribute does not work for user-defined logger but works for root logger.
Now things getting clearer. Log4j maintains a logger hierarchy which is determined by the dot withing the logger names, similar to the package hierarchy in java.Example: Config: you declare a logger foo.bar and a root logger, both have one (the same) appender attached. Code: class foo.bar.XY instantiates the logger foo.bar.XY and issues a log call to it. - Log4j will look for a logger foo.bar.XY which is not declared. After that it climbs up the hierarchy path. Thus it looks for logger foo.bar which is found. The appenders of this logger will be served. Now the additivity flag comes into play. If it is set to true (the default), log4j will go on searching the next higher logger in hierarchy foo. No logger will be found. At the end it reaches the root logger and serves the appenders of the root logger. If the additivity flag of foo.bar would be set to false, log4j would stop looking further up for more loggers. With additivity=true you will end up to have the same log statement twice in your appender, with additivity=false only the appenders of the logger foo.bar were served. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 6:22 PM To: log4j-user@logging.apache.org Subject: Re: additivity attribute does not work for user-defined logger but works for root logger. Thanks for your answer and your time. Why the root logger defined: root level value=debug/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root knows that all the logs from ALL the classes should go the the file specified by appenders:taskRedirection, addQuestionSequenceOrder and a logger: logger name=curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter additivity=true level value=debug/ appender-ref ref=addQuestionSequenceOrder/ /logger knows that ONLY logs from that class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter has to be served? Is no't realy any way to duplcate the work of the root logger in logger specified by the name curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter? If not, why this parameter additivity=true is present at all? It does nothing. MR. Thorbjørn Ravn Andersen wrote: Camer38 skrev den 03-07-2008 15:25: My assumption was that if I run one of the class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter I would got all the logs from that class and all the classes used internally by curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in the addQuestionSequenceOrderTool.log. No. The logger frameworks do not do magic to deduce where logging should go. If you want for classes called to use a specific logger, you must pass it as an argument like all values you want to use. Instead I got an log4j warning: log4j:WARN No appenders could be found for logger (curam.tools.upgradehelper.util.SQLStatements). You are most likely using a logger variable in SQLStatements which has been defined at the top of that class referring to SQLStatments.class. This does not allow log4j to distinguish between the two cases you have. I have the same problem in a project where it is two threads logging in the same file. I have not yet found a good solution. During my testing I have defined a root logger as well, but it does not do what I want. All the expected lines are present in both files but the files are populated with the log from the same class. root level value=info/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root This say that you want all messages at info level or higher to go to both the taskRedirection appender AND the addQuestionSequenceOrder appender. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work -for-user-defined-logger-but-works-for-root-logger.-tp18259092 p18263109.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]
RE: additivity attribute does not work for user-defined logger but works for root logger.
Thank you very much for the explanation. It makes perfect sense for me. But in my case I hit slightly different problem. The class foo.bar.XY calls lets say test.bulk.ZY and the class com.create.CR calls test.bulk.ZY as well. I need two full log files for foo.bar.XY and test.bulk.ZY with all the logs information from test.bulk.ZY. How to do that with two loggers defined for each of the foo.bar.XY and test.bulk.ZY? Bender Heri wrote: Now things getting clearer. Log4j maintains a logger hierarchy which is determined by the dot withing the logger names, similar to the package hierarchy in java.Example: Config: you declare a logger foo.bar and a root logger, both have one (the same) appender attached. Code: class foo.bar.XY instantiates the logger foo.bar.XY and issues a log call to it. - Log4j will look for a logger foo.bar.XY which is not declared. After that it climbs up the hierarchy path. Thus it looks for logger foo.bar which is found. The appenders of this logger will be served. Now the additivity flag comes into play. If it is set to true (the default), log4j will go on searching the next higher logger in hierarchy foo. No logger will be found. At the end it reaches the root logger and serves the appenders of the root logger. If the additivity flag of foo.bar would be set to false, log4j would stop looking further up for more loggers. With additivity=true you will end up to have the same log statement twice in your appender, with additivity=false only the appenders of the logger foo.bar were served. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 6:22 PM To: log4j-user@logging.apache.org Subject: Re: additivity attribute does not work for user-defined logger but works for root logger. Thanks for your answer and your time. Why the root logger defined: root level value=debug/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root knows that all the logs from ALL the classes should go the the file specified by appenders:taskRedirection, addQuestionSequenceOrder and a logger: logger name=curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter additivity=true level value=debug/ appender-ref ref=addQuestionSequenceOrder/ /logger knows that ONLY logs from that class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter has to be served? Is no't realy any way to duplcate the work of the root logger in logger specified by the name curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter? If not, why this parameter additivity=true is present at all? It does nothing. MR. Thorbjørn Ravn Andersen wrote: Camer38 skrev den 03-07-2008 15:25: My assumption was that if I run one of the class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter I would got all the logs from that class and all the classes used internally by curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in the addQuestionSequenceOrderTool.log. No. The logger frameworks do not do magic to deduce where logging should go. If you want for classes called to use a specific logger, you must pass it as an argument like all values you want to use. Instead I got an log4j warning: log4j:WARN No appenders could be found for logger (curam.tools.upgradehelper.util.SQLStatements). You are most likely using a logger variable in SQLStatements which has been defined at the top of that class referring to SQLStatments.class. This does not allow log4j to distinguish between the two cases you have. I have the same problem in a project where it is two threads logging in the same file. I have not yet found a good solution. During my testing I have defined a root logger as well, but it does not do what I want. All the expected lines are present in both files but the files are populated with the log from the same class. root level value=info/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root This say that you want all messages at info level or higher to go to both the taskRedirection appender AND the addQuestionSequenceOrder appender. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work -for-user-defined-logger-but-works-for-root-logger.-tp18259092 p18263109.html Sent from the Log4j - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
RE: additivity attribute does not work for user-defined logger but works for root logger.
Questions see inline. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2008 3:24 PM To: log4j-user@logging.apache.org Subject: RE: additivity attribute does not work for user-defined logger but works for root logger. But in my case I hit slightly different problem. The class foo.bar.XY calls lets say test.bulk.ZY and the class com.create.CR calls test.bulk.ZY as well. Do this two classes (foo.bar.XY and com.create.CR) run in different threads? Or is it the same thread? - Influences possible solutions! I need two full log files for foo.bar.XY and test.bulk.ZY with all the logs information from test.bulk.ZY. Does not make any sense for me. Is it a typo? (test.bulk.ZY in first line should be com.create.CR?). If so, then next question: Do you want the logs of test.bulk.ZY which were called by foo.bar.XY in the log file of foo.bar and the logs of test.bulk.ZY which were called by com.create.CR in the log file of com.create.CR? Otherwise you have to explain more detailled which log calls you want to appear in which appender. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: additivity attribute does not work for user-defined logger but works for root logger.
Yes, it is a typo. Should be: I need two full log files for foo.bar.XY and com.create.CR with all the logs information from test.bulk.ZY Yes the foo.bar.XY and com.create.CR are run in different threads. I want two logs files - one for foo.bar.XY and the second one for com.create.CR. All of them should have all the calls made in test.bulk.ZY (treat it as utility class) Do you want the logs of test.bulk.ZY which were called by foo.bar.XY in the log file of foo.bar.XY and the logs of test.bulk.ZY which were called by com.create.CR in the log file of com.create.CR? Yes. the foo.bar.XY and com.create.CR has some logging messages as well that needs to go to the right log file. Thanks for helping me with it. M. Bender Heri wrote: Questions see inline. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2008 3:24 PM To: log4j-user@logging.apache.org Subject: RE: additivity attribute does not work for user-defined logger but works for root logger. But in my case I hit slightly different problem. The class foo.bar.XY calls lets say test.bulk.ZY and the class com.create.CR calls test.bulk.ZY as well. Do this two classes (foo.bar.XY and com.create.CR) run in different threads? Or is it the same thread? - Influences possible solutions! I need two full log files for foo.bar.XY and test.bulk.ZY with all the logs information from test.bulk.ZY. Does not make any sense for me. Is it a typo? (test.bulk.ZY in first line should be com.create.CR?). If so, then next question: Do you want the logs of test.bulk.ZY which were called by foo.bar.XY in the log file of foo.bar and the logs of test.bulk.ZY which were called by com.create.CR in the log file of com.create.CR? Otherwise you have to explain more detailled which log calls you want to appear in which appender. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work-for-user-defined-logger-but-works-for-root-logger.-tp18259092p18319243.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]
RE: additivity attribute does not work for user-defined logger but works for root logger.
OK, in the following I denote foo.bar.XY as AppA and com.create.CR as AppB and the test.bulk.ZY as UtilityC. Possible solutions: 1. If the UtilityC is instantiated separatly by AppA and AppB (two instances) you are perfectly done by configuring each instance with the desired logger: Config: appender A appender B Logger AppA with appender A Logger AppB with appender B Logger AppA.UtilityC with appender A Logger AppB.UtilityC with appender B Code: Use the suggestion of jake Kjome from today morning. The constructor of SQLStatements wich receives the classname of the calling class must then expand the logger name: receivedClassName + . + this.getClass.getSimpleName(). With this logger name you retrieve the logger from the repository. If AppA had called the constructor, you get the Logger AppA.UtilityC, and so on. 2. Supply the desired logger on each call to the UtilityC class: public static void UtilityC.doSomething( Logger aLoggerToUse ); {...} Drawback: The location info in the log statements would be the location of the call to doSomething(). You can avoid this by using in the UtilityC the generic call of Logger log(): aLoggerToUse.log ( this.getClass.getName(), Level.DEBUG, logMsg, aThrowable ) 3. Since the AppA and AppB run in different threads you could use a MDC value within UtilityC in order to distinguish the loggers. Maybe in combination with a own Repository-Selector which relies on the actual values in MDC. Search the archive, this was discussed a lot, and I supplied whole examples. I hope you got the hint in which direction you should think. Otherwise ask again. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2008 5:23 PM To: log4j-user@logging.apache.org Subject: RE: additivity attribute does not work for user-defined logger but works for root logger. Yes, it is a typo. Should be: I need two full log files for foo.bar.XY and com.create.CR with all the logs information from test.bulk.ZY Yes the foo.bar.XY and com.create.CR are run in different threads. I want two logs files - one for foo.bar.XY and the second one for com.create.CR. All of them should have all the calls made in test.bulk.ZY (treat it as utility class) Do you want the logs of test.bulk.ZY which were called by foo.bar.XY in the log file of foo.bar.XY and the logs of test.bulk.ZY which were called by com.create.CR in the log file of com.create.CR? Yes. the foo.bar.XY and com.create.CR has some logging messages as well that needs to go to the right log file. Thanks for helping me with it. M. Bender Heri wrote: Questions see inline. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2008 3:24 PM To: log4j-user@logging.apache.org Subject: RE: additivity attribute does not work for user-defined logger but works for root logger. But in my case I hit slightly different problem. The class foo.bar.XY calls lets say test.bulk.ZY and the class com.create.CR calls test.bulk.ZY as well. Do this two classes (foo.bar.XY and com.create.CR) run in different threads? Or is it the same thread? - Influences possible solutions! I need two full log files for foo.bar.XY and test.bulk.ZY with all the logs information from test.bulk.ZY. Does not make any sense for me. Is it a typo? (test.bulk.ZY in first line should be com.create.CR?). If so, then next question: Do you want the logs of test.bulk.ZY which were called by foo.bar.XY in the log file of foo.bar and the logs of test.bulk.ZY which were called by com.create.CR in the log file of com.create.CR? Otherwise you have to explain more detailled which log calls you want to appear in which appender. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work -for-user-defined-logger-but-works-for-root-logger.-tp18259092 p18319243.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]
Re: additivity attribute does not work for user-defined logger but works for root logger.
Camer38 wrote: I have two Java classes that used log4j. curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter and curam.tools.upgradehelper.taskredirection.TaskRedirectionConverter Both classes from above uses different class: curam.tools.upgradehelper.util.SQLStatements where a logger in each of the class with defined in following pattern: private static final Logger log = Logger.getLogger(NameOfTheClass.class); Next I have defined log4j.xml. I want to have a full log file in two separate files for both classes. curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in QuestionSequenceOrderConverterTool.log curam.tools.upgradehelper.taskredirection.TaskRedirectionConverter in TaskRedirectionConverterTool.log I did a following: I have not defined root at all. My assumption was that if I run one of the class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter I would got all the logs from that class and all the classes used internally by curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in the addQuestionSequenceOrderTool.log. That's simply not the way Log4j works. Logger naming is hierarchical, and though this does not have to be packaged-based, that's the traditional usage. Instead I got an log4j warning: log4j:WARN No appenders could be found for logger (curam.tools.upgradehelper.util.SQLStatements). ...because curam.tools.upgradehelper.util.SQLStatements is not part of the naming hierarchy of either of the defined loggers. This is why you usually define the ROOT logger as a catch-all. What is the meaning of the attribute additivity for each logger? Why don't I get all the logs in one file? During my testing I have defined a root logger as well, but it does not do what I want. All the expected lines are present in both files but the files are populated with the log from the same class. root level value=info/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root As I said previously, using package names is the traditional usage, but it's not the only way to name loggers. You can use any arbitrary naming scheme. Of course, the problem you are running into here is that you want one utility class's logging to go to one of two separate files depending on which class used the utility. That's only possible if you design the utility class to change it's logging name each time it is used. You'll have do add a constructor that takes a logger name, such as... public SQLStatements(String loggerName) {...} And then each time you use this helper class, pass in the logger name to use. For instance... public class QuestionSequenceOrderConverter { public void doSomething() { SQLStatements ss = new SQLStatements(this.getClass().getName()); } } The other way to do this is to use something like SLF4J/Logback's Markers to associate distinct loggers in a user-defined way. Log4j 1.3 started with this, but it was abandoned. I believe there's work in progress for something like this in the Log4j extras or companions, though i can't remember what it's called, offhand? I use log4j-1.2.15.jar Could anybody help me with defining a correct log4j.xml file? You're looking for additivity=false, not true. Of course, you will get zero entries for the two specifically named loggers with additivity=false in output to the appenders attached to the ROOT logger. Hopefully that's not a problem. logger name=curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter additivity=false level value=debug/ appender-ref ref=addQuestionSequenceOrder/ /logger logger name=curam.tools.upgradehelper.taskredirection.TaskRedirectionConverter additivity=false level value=debug/ appender-ref ref=taskRedirection/ /logger root level value=warn/ appender-ref ref=allOtherCasesAppender/ /root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: additivity attribute does not work for user-defined logger but works for root logger.
Jacob Kjome skrev den 07-07-2008 08:11: logging name each time it is used. You'll have do add a constructor that takes a logger name, such as... public SQLStatements(String loggerName) {...} And then each time you use this helper class, pass in the logger name to use. For instance... Another option is just passing in another Logger object in the call to the method. That may confuse a maintainer though. I spent some time a while ago locating a logger which had been initialized with the wrong class so the messages came from a different class. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: additivity attribute does not work for user-defined logger but works for root logger.
Thanks. So, is it any way to define a logger to works the same way as root logger does? Carol Enderlin wrote: My answers below... Why the root logger defined: root level value=debug/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root knows that all the logs from ALL the classes should go the the file specified by appenders:taskRedirection, addQuestionSequenceOrder That's the way it's supposed to work, root logger gets everything unless you configure it not to. and a logger: logger name=curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter additivity=true level value=debug/ appender-ref ref=addQuestionSequenceOrder/ /logger knows that ONLY logs from that class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter has to be served? That's the way that is supposed to work, too. You can get less specific and get all classes in a package hierarchy to log to a logger. Example: logger name=curam.tools.upgradehelper ... If not, why this parameter additivity=true is present at all? It does nothing. additivity is true by default, so you are correct that setting additivity=true doesn't change the behavior. There is an excellent description of how additivity works in log4j short manual http://logging.apache.org/log4j/1.2/manual.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work-for-user-defined-logger-but-works-for-root-logger.-tp18259092p18275249.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]
RE: additivity attribute does not work for user-defined logger but works for root logger.
Please provide your full log4j.xml. Heri -Original Message- From: Camer38 [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2008 3:26 PM To: log4j-user@logging.apache.org Subject: additivity attribute does not work for user-defined logger but works for root logger. I have two Java classes that used log4j. curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter and curam.tools.upgradehelper.taskredirection.TaskRedirectionConverter Both classes from above uses different class: curam.tools.upgradehelper.util.SQLStatements where a logger in each of the class with defined in following pattern: private static final Logger log = Logger.getLogger(NameOfTheClass.class); Next I have defined log4j.xml. I want to have a full log file in two separate files for both classes. curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in QuestionSequenceOrderConverterTool.log curam.tools.upgradehelper.taskredirection.TaskRedirectionConve rter in TaskRedirectionConverterTool.log I did a following: I have not defined root at all. My assumption was that if I run one of the class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter I would got all the logs from that class and all the classes used internally by curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in the addQuestionSequenceOrderTool.log. Instead I got an log4j warning: log4j:WARN No appenders could be found for logger (curam.tools.upgradehelper.util.SQLStatements). What is the meaning of the attribute additivity for each logger? Why don't I get all the logs in one file? During my testing I have defined a root logger as well, but it does not do what I want. All the expected lines are present in both files but the files are populated with the log from the same class. root level value=info/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root I use log4j-1.2.15.jar Could anybody help me with defining a correct log4j.xml file? -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work -for-user-defined-logger-but-works-for-root-logger.-tp18259092 p18259092.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]
RE: additivity attribute does not work for user-defined logger but works for root logger.
It is correct log4j.xml log4j:configuration debug=true xmlns:log4j=http://jakarta.apache.org/log4j/; appender name=addQuestionSequenceOrder class=org.apache.log4j.RollingFileAppender layout class=org.apache.log4j.PatternLayout /layout /appender appender name=taskRedirection class=org.apache.log4j.RollingFileAppender layout class=org.apache.log4j.PatternLayout /layout /appender logger name=curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter additivity=true level value=debug/ appender-ref ref=addQuestionSequenceOrder/ /logger logger name=curam.tools.upgradehelper.taskredirection.TaskRedirectionConverter level value=info/ appender-ref ref=taskRedirection/ /logger /log4j:configuration -- View this message in context: http://www.nabble.com/%22additivity%22-attribute-does-not-work-for-user-defined-logger-but-works-for-root-logger.-tp18259092p18261411.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]
Re: additivity attribute does not work for user-defined logger but works for root logger.
Camer38 skrev den 03-07-2008 15:25: My assumption was that if I run one of the class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter I would got all the logs from that class and all the classes used internally by curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter in the addQuestionSequenceOrderTool.log. No. The logger frameworks do not do magic to deduce where logging should go. If you want for classes called to use a specific logger, you must pass it as an argument like all values you want to use. Instead I got an log4j warning: log4j:WARN No appenders could be found for logger (curam.tools.upgradehelper.util.SQLStatements). You are most likely using a logger variable in SQLStatements which has been defined at the top of that class referring to SQLStatments.class. This does not allow log4j to distinguish between the two cases you have. I have the same problem in a project where it is two threads logging in the same file. I have not yet found a good solution. During my testing I have defined a root logger as well, but it does not do what I want. All the expected lines are present in both files but the files are populated with the log from the same class. root level value=info/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root This say that you want all messages at info level or higher to go to both the taskRedirection appender AND the addQuestionSequenceOrder appender. -- Thorbjørn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: additivity attribute does not work for user-defined logger but works for root logger.
My answers below... Why the root logger defined: root level value=debug/ appender-ref ref=taskRedirection/ appender-ref ref=addQuestionSequenceOrder/ /root knows that all the logs from ALL the classes should go the the file specified by appenders:taskRedirection, addQuestionSequenceOrder That's the way it's supposed to work, root logger gets everything unless you configure it not to. and a logger: logger name=curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter additivity=true level value=debug/ appender-ref ref=addQuestionSequenceOrder/ /logger knows that ONLY logs from that class curam.tools.upgradehelper.ieg.QuestionSequenceOrderConverter has to be served? That's the way that is supposed to work, too. You can get less specific and get all classes in a package hierarchy to log to a logger. Example: logger name=curam.tools.upgradehelper ... If not, why this parameter additivity=true is present at all? It does nothing. additivity is true by default, so you are correct that setting additivity=true doesn't change the behavior. There is an excellent description of how additivity works in log4j short manual http://logging.apache.org/log4j/1.2/manual.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]