[JBoss-dev] log4j switchover - anyone working on this?
Hi, I'd like to fix the org.jboss.logging deprecation messages - which means replacing the logging with log4j calls... So - is anyone doing this already? I plan to look for code that has the correct logging and doing like-wise - so any recommendations? I am assuming that there is no reason for not fully switching over to log4j... Regards, Chris = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Hi, I'd like to fix the org.jboss.logging deprecation messages - which means replacing the logging with log4j calls... So - is anyone doing this already? I plan to look for code that has the correct logging and doing like-wise - so any recommendations? What do you mean by changing code that has the correct logging? I am assuming that there is no reason for not fully switching over to log4j... No reason not to. Regards, Chris ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Hi, --- Scott M Stark [EMAIL PROTECTED] wrote: I plan to look for code that has the correct logging and doing like-wise - so any recommendations? What do you mean by changing code that has the correct logging? umm, perhaps correct is the wrong phrase. I mean look for jboss code that is using log4j - I presume some is - and then use that as a model for making the non-log4j bits use log4j... Chris = Need somewhere to Live in London - http://freeflats.com __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Ok. Just moving to log4j to avoid deprecation warning is not worth the effort as we need to define a logging usage pattern and then move to it. One big issue we have right now is that debug msgs are anything from verbose one-time initialization mgs to per method traces of activity. The server.log is inundated with output when any type of client throughput is seen. For example, running the testsuite produces a 3Mb log file in 9 minutes. I added a custom TRACE priority to allow finer granularity of debugging msgs. The notion is that TRACE level msgs are those that are issued as a result of some request while DEBUG msgs are not. We need to agree on and formalize our logging convention and then move to it. - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 11:30 AM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Hi, --- Scott M Stark [EMAIL PROTECTED] wrote: I plan to look for code that has the correct logging and doing like-wise - so any recommendations? What do you mean by changing code that has the correct logging? umm, perhaps correct is the wrong phrase. I mean look for jboss code that is using log4j - I presume some is - and then use that as a model for making the non-log4j bits use log4j... Chris ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Hi, So far I have been unsuccessful in turning on the TRACE priority -- thus the excessive DEBUG stuff I have been using. Do you have an example of how to turn it on? If I can get it to work I will happily turn most of my debugs into traces. Thanks david jencks On 2001.09.10 15:12:06 -0400 Scott M Stark wrote: Ok. Just moving to log4j to avoid deprecation warning is not worth the effort as we need to define a logging usage pattern and then move to it. One big issue we have right now is that debug msgs are anything from verbose one-time initialization mgs to per method traces of activity. The server.log is inundated with output when any type of client throughput is seen. For example, running the testsuite produces a 3Mb log file in 9 minutes. I added a custom TRACE priority to allow finer granularity of debugging msgs. The notion is that TRACE level msgs are those that are issued as a result of some request while DEBUG msgs are not. We need to agree on and formalize our logging convention and then move to it. - Original Message - From: Chris Kimpton [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 11:30 AM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Hi, --- Scott M Stark [EMAIL PROTECTED] wrote: I plan to look for code that has the correct logging and doing like-wise - so any recommendations? What do you mean by changing code that has the correct logging? umm, perhaps correct is the wrong phrase. I mean look for jboss code that is using log4j - I presume some is - and then use that as a model for making the non-log4j bits use log4j... Chris ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Yes, there is an example in the default log4j.properties file that is commented out. Simply uncomment the last line as follows: # An example of enabling the custom TRACE level priority that is used # by the JBoss internals to diagnose low level details. This example # turns on TRACE level msgs for the org.jboss.ejb.plugins package and its # subpackages. This will produce A LOT of logging output. log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.log4j.TracePrio rity If you now invoke an ejb method you will see a large number of messages detailing the activity of the Entity instance locking for example(provided that was not dropped in the RH changes). Before rushing off to switch to using this custom priority however, I would like to have an agreement that is the best way to do this. - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 12:54 PM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Hi, So far I have been unsuccessful in turning on the TRACE priority -- thus the excessive DEBUG stuff I have been using. Do you have an example of how to turn it on? If I can get it to work I will happily turn most of my debugs into traces. Thanks david jencks On 2001.09.10 15:12:06 -0400 Scott M Stark wrote: Ok. Just moving to log4j to avoid deprecation warning is not worth the effort as we need to define a logging usage pattern and then move to it. One big issue we have right now is that debug msgs are anything from verbose one-time initialization mgs to per method traces of activity. The server.log is inundated with output when any type of client throughput is seen. For example, running the testsuite produces a 3Mb log file in 9 minutes. I added a custom TRACE priority to allow finer granularity of debugging msgs. The notion is that TRACE level msgs are those that are issued as a result of some request while DEBUG msgs are not. We need to agree on and formalize our logging convention and then move to it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Are we still planning on dropping the older Log Logger stuff in favor of Log4j? If so, lets replace Logger with a new class that extends from Category, and provides Logger create() methods to access an instance. It would have the trace() and isTraceEnabled(). Trace seems to be best suited for detailed debug messages, which are only enabled for tracking down server internals. In most cases I would like to run JBoss with debug enabled, but I don't want to get flooded with tons of messages. IMHO, debug messages should provide adequte brief information, which could be used to track down a problem, and trace is used to provide as much information as possible. --jason On Mon, 10 Sep 2001, Scott M Stark wrote: Yes, there is an example in the default log4j.properties file that is commented out. Simply uncomment the last line as follows: # An example of enabling the custom TRACE level priority that is used # by the JBoss internals to diagnose low level details. This example # turns on TRACE level msgs for the org.jboss.ejb.plugins package and its # subpackages. This will produce A LOT of logging output. log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.log4j.TracePrio rity If you now invoke an ejb method you will see a large number of messages detailing the activity of the Entity instance locking for example(provided that was not dropped in the RH changes). Before rushing off to switch to using this custom priority however, I would like to have an agreement that is the best way to do this. - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 12:54 PM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Hi, So far I have been unsuccessful in turning on the TRACE priority -- thus the excessive DEBUG stuff I have been using. Do you have an example of how to turn it on? If I can get it to work I will happily turn most of my debugs into traces. Thanks david jencks On 2001.09.10 15:12:06 -0400 Scott M Stark wrote: Ok. Just moving to log4j to avoid deprecation warning is not worth the effort as we need to define a logging usage pattern and then move to it. One big issue we have right now is that debug msgs are anything from verbose one-time initialization mgs to per method traces of activity. The server.log is inundated with output when any type of client throughput is seen. For example, running the testsuite produces a 3Mb log file in 9 minutes. I added a custom TRACE priority to allow finer granularity of debugging msgs. The notion is that TRACE level msgs are those that are issued as a result of some request while DEBUG msgs are not. We need to agree on and formalize our logging convention and then move to it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
We need to agree on and formalize our logging convention and then move to it. Let us do this. Logging is a critical system. What is left to decide? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
- Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 2:41 PM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Are we still planning on dropping the older Log Logger stuff in favor of Log4j? If so, lets replace Logger with a new class that extends from Category, and provides Logger create() methods to access an instance. It would have the trace() and isTraceEnabled(). Yes that is the plan but this is what I want agreement on. Trace seems to be best suited for detailed debug messages, which are only enabled for tracking down server internals. In most cases I would like to run JBoss with debug enabled, but I don't want to get flooded with tons of messages. IMHO, debug messages should provide adequte brief information, which could be used to track down a problem, and trace is used to provide as much information as possible. This is my view of logging as well. --jason On Mon, 10 Sep 2001, Scott M Stark wrote: Yes, there is an example in the default log4j.properties file that is commented out. Simply uncomment the last line as follows: # An example of enabling the custom TRACE level priority that is used # by the JBoss internals to diagnose low level details. This example # turns on TRACE level msgs for the org.jboss.ejb.plugins package and its # subpackages. This will produce A LOT of logging output. log4j.category.org.jboss.ejb.plugins=TRACE#org.jboss.logging.log4j.TracePrio rity If you now invoke an ejb method you will see a large number of messages detailing the activity of the Entity instance locking for example(provided that was not dropped in the RH changes). Before rushing off to switch to using this custom priority however, I would like to have an agreement that is the best way to do this. - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 12:54 PM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Hi, So far I have been unsuccessful in turning on the TRACE priority -- thus the excessive DEBUG stuff I have been using. Do you have an example of how to turn it on? If I can get it to work I will happily turn most of my debugs into traces. Thanks david jencks On 2001.09.10 15:12:06 -0400 Scott M Stark wrote: Ok. Just moving to log4j to avoid deprecation warning is not worth the effort as we need to define a logging usage pattern and then move to it. One big issue we have right now is that debug msgs are anything from verbose one-time initialization mgs to per method traces of activity. The server.log is inundated with output when any type of client throughput is seen. For example, running the testsuite produces a 3Mb log file in 9 minutes. I added a custom TRACE priority to allow finer granularity of debugging msgs. The notion is that TRACE level msgs are those that are issued as a result of some request while DEBUG msgs are not. We need to agree on and formalize our logging convention and then move to it. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
I think just the custom logging class that replaces the existing Log, Logger and JBossCategory and the use of TRACE. I'm in agreement with you on this items so unless there is other input to the contrary the details of the new Logger or whatever is all that remains. Due to the proposed change to have a Logger class in log4j we probably don't want to use Logger as a classname to minmize name clash issues. - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 2:45 PM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? We need to agree on and formalize our logging convention and then move to it. Let us do this. Logging is a critical system. What is left to decide? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
I think just the custom logging class that replaces the existing Log, Logger
and
JBossCategory and the use of TRACE. I'm in agreement with you on this
items so unless there is other input to the contrary the details of the new
Logger or
whatever is all that remains.
What about the current Log.setLog() stuff? Will that go away? It was one
of the priary reasons that I did not convert some components to Log4j.
Due to the proposed change to have a Logger class in
log4j we probably don't want to use Logger as a classname to minmize name
clash issues.
There is no reason why we can not use Logger, I would not suggest anything
else. There will be almost no reasons to import org.jboss.log.Logger and
org.apache.log4j.Logger, we will simply use our version. Applications can
choose which they prefer and use it.
Only our Logger impl will have to worry about the Log4j Logger, but simply
put:
public class Logger
extends org.apache.log4j.Logger
{
// ...
}
--jason
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Because I don't want redundant interfaces to the logging system. - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 10, 2001 4:14 PM Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? What is wrong with rewriting all code using Log and Logger to use JBossCategory instead? It's easy and often you can improve things by eg category.error(message, exception) what am I missing here? david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
From: Jason Dillon [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Date: Mon, 10 Sep 2001 14:41:20 -0700 (PDT) Are we still planning on dropping the older Log Logger stuff in favor of Log4j? If so, lets replace Logger with a new class that extends from Category, and provides Logger create() methods to access an instance. It would have the trace() and isTraceEnabled(). If going with this approach, just a isTraceEnabled public variable so that you don't incure the cost of a method call. (since you'll be doing the check to avoid the cost a trace method call in the first place.) Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
Forgive the ignorance, I spoke without a full understanding of how log4j works.. Regards, HIram From: Scott M Stark [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Date: Mon, 10 Sep 2001 17:33:00 -0700 This can't be done as wether or not the priority is enabled is a dynamic function of the category heirchary and a method call must be made to query. Walk through a JMS msg delivery or EJB method invocation and count the method calls and then come back and tell me this amounts to even .01% of the total. If going with this approach, just a isTraceEnabled public variable so that you don't incure the cost of a method call. (since you'll be doing the check to avoid the cost a trace method call in the first place.) Regards, Hiram ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] log4j switchover - anyone working on this?
The reason for the isXXXEnabled() methods is not the cost of the method call which is minimal but to avoid constructing the log arguments which typically involve a bunch of string manipulation which is time consuming. The category.debug() call itself is very quick. david jencks On 2001.09.10 19:42:08 -0400 Hiram Chirino wrote: From: Jason Dillon [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] log4j switchover - anyone working on this? Date: Mon, 10 Sep 2001 14:41:20 -0700 (PDT) Are we still planning on dropping the older Log Logger stuff in favor of Log4j? If so, lets replace Logger with a new class that extends from Category, and provides Logger create() methods to access an instance. It would have the trace() and isTraceEnabled(). If going with this approach, just a isTraceEnabled public variable so that you don't incure the cost of a method call. (since you'll be doing the check to avoid the cost a trace method call in the first place.) Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
