Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 15-12-2008 11:19: Sure. SLF4J delegates to log4j (via slf4j-log4j12.jar). I now realize that the instructions in my mail of 12-12-2008 did not mention slf4j-log4j12.jar. Did you add slf4j-log4j12.jar to your class path? I must have. I just didn't remember to check before responding to the mail, and thought I missed something in the process. Thank you. I am not doubting, just not understanding, there is a difference O:) -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Thorbjørn Ravn Andersen wrote: Ceki Gulcu skrev den 12-12-2008 16:01: To run this test, in addition to junit4.jar, you need to have slf4j-api.jar, apache-log4j-extras-1.1-SNAPSHOT.jar and log4j.jar on your class path. On my machine the output is: LogMF avg=15251 SLF4J avg=4964 On my machine (which is low on RAM) I get these numbers with JDK 1.5 SLF4J avg=6085 LogMF avg=12582 I understand how you get the LogMF method to write to ytest.log, but not how the slf4j method does it. Would you care to elaborate? Sure. SLF4J delegates to log4j (via slf4j-log4j12.jar). I now realize that the instructions in my mail of 12-12-2008 did not mention slf4j-log4j12.jar. Did you add slf4j-log4j12.jar to your class path? To check that the testSLF4J actually writes to ytest.log via log4j, disable "testLogMF()" by adding the @Ignore annotation before the testLogMF() method. You should see that ytest.log file increases in size as testSLF4J() logs into it via log4j, as it should. (If you have any lingering doubts that log4j is the underlying framework, you can run the tests in a debugger.) This shows that an enabled logging statement runs three times faster when logging via SLF4J than when logging through LogMF, with log4j as the underlying logging framework. Not only is the SLF4J formatter faster, it makes a "noticeable" difference when the logs are actually written to destination. This is a very substantial difference, so if the LogMF approach is to be used some kind of mechanism should be used to optimize - a weak reference cache of the MessageFormatter with the format string as key - but if the simpler approach is faster I would personally go with that. -- Ceki Gülcü - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 12-12-2008 16:01: To run this test, in addition to junit4.jar, you need to have slf4j-api.jar, apache-log4j-extras-1.1-SNAPSHOT.jar and log4j.jar on your class path. On my machine the output is: LogMF avg=15251 SLF4J avg=4964 On my machine (which is low on RAM) I get these numbers with JDK 1.5 SLF4J avg=6085 LogMF avg=12582 I understand how you get the LogMF method to write to ytest.log, but not how the slf4j method does it. Would you care to elaborate? This shows that an enabled logging statement runs three times faster when logging via SLF4J than when logging through LogMF, with log4j as the underlying logging framework. Not only is the SLF4J formatter faster, it makes a "noticeable" difference when the logs are actually written to destination. This is a very substantial difference, so if the LogMF approach is to be used some kind of mechanism should be used to optimize - a weak reference cache of the MessageFormatter with the format string as key - but if the simpler approach is faster I would personally go with that. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 13, 2008, at 10:02 AM, Curt Arnold wrote: On Dec 13, 2008, at 3:09 AM, Ralph Goers wrote: On Dec 12, 2008, at 11:59 PM, Scott Deboy wrote: Which logback features? Are they a part of SLF4j's API? A combination. I needed Markers and I've added some minor stuff to the SLF4J extensions. What I really needed were the TurboFilters in Logback. Take a look at DynamicThresholdFilter (and note the authors names). Also, the stack trace support in Log4j was really awful. Curt recently improved it as best he can while still supporting ancient JDKs. Are there Bugzilla issues for these? If not, please create them. They were added as LOG4J2-17 and LOG4J2-18. They seemed more appropriate to target for 2.0. As for TurboFilters, it looks like this is a hierarchy-wide filter that can be evaluated prior to creating the LoggingEvent (which is expensive). I'd like to avoid adding a new concept, but could see that a new interface that could be used to advertise a filter can make a preliminary determination prior to LoggingEvent creation. This could go in log4j 1.x but has to go into the core, not a companion. I've never been comfortable with Markers since I've never seen a clear definition of the problem they are trying to solve. They were just introduced as a completed design without any public discussion of the motivating problems which may have lead to a different solution. I'd love to see a generic Bugzilla entry that said "We need a solution for this use case or use cases" and not "We need markers".You You can see one small example if you look at XLogger is SLF4J's extension subproject. Both entry and exit are at the trace level. The marker allows them to be differentiated from other trace events so that Appenders can deal with them in a special way if desired. When used in combination with a TurboFilter it makes adding an entry and exit to virtually every method cost almost nothing when the FLOW marker is filtered out. But other trace events might still be allowed. Markers are also useful if you want to use the logging framework for audit logging. In short, they let you treat your logging events at a much more granular level. Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 13, 2008, at 3:09 AM, Ralph Goers wrote: On Dec 12, 2008, at 11:59 PM, Scott Deboy wrote: Which logback features? Are they a part of SLF4j's API? A combination. I needed Markers and I've added some minor stuff to the SLF4J extensions. What I really needed were the TurboFilters in Logback. Take a look at DynamicThresholdFilter (and note the authors names). Also, the stack trace support in Log4j was really awful. Curt recently improved it as best he can while still supporting ancient JDKs. Are there Bugzilla issues for these? If not, please create them. As for TurboFilters, it looks like this is a hierarchy-wide filter that can be evaluated prior to creating the LoggingEvent (which is expensive). I'd like to avoid adding a new concept, but could see that a new interface that could be used to advertise a filter can make a preliminary determination prior to LoggingEvent creation. This could go in log4j 1.x but has to go into the core, not a companion. I've never been comfortable with Markers since I've never seen a clear definition of the problem they are trying to solve. They were just introduced as a completed design without any public discussion of the motivating problems which may have lead to a different solution. I'd love to see a generic Bugzilla entry that said "We need a solution for this use case or use cases" and not "We need markers". - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 12, 2008, at 11:59 PM, Scott Deboy wrote: Which logback features? Are they a part of SLF4j's API? A combination. I needed Markers and I've added some minor stuff to the SLF4J extensions. What I really needed were the TurboFilters in Logback. Take a look at DynamicThresholdFilter (and note the authors names). Also, the stack trace support in Log4j was really awful. Curt recently improved it as best he can while still supporting ancient JDKs. Also Log4j suffers from the same locking issues Logback did. The synchronized block in Category.callAppenders can be a huge bottleneck in certain circumstances. At a quess I'd bet https://issues.apache.org/activemq/browse/AMQ-1861and http://forums.sun.com/thread.jspa?threadID=5234863 are both related to this. Doing a google on "Log4j callAppenders lock" shows many hits of folks having locking issues. FWIW, Logback hasn't completely fixed the problem. Many Appenders are still completely synchronized. Ralph
RE: [PROPOSAL] Implementing the SLF4J API directly
Which logback features? Are they a part of SLF4j's API? Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 sde...@comotivsystems.com www.comotivsystems.com -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Fri 12/12/2008 6:32 PM To: Log4J Developers List Subject: Re: [PROPOSAL] Implementing the SLF4J API directly I suppose that is fair. But I will tell you that I am biased. I use SLF4J. Right now I can't use log4j because it is missing features that Logback has. The primary reason I asked to be involved in Log4j 2.0 was so that I could address that. Obviously I haven't had the time to get started but I still intend to. Maybe that will be what I do over the Christmas holiday. So whether SLF4J is added to 1.2 doesn't really matter to me. Ralph On Dec 12, 2008, at 4:45 PM, Scott Deboy wrote: > I had two points I was trying to make: > > 1. Whether or not the slf4j formatter is faster by x nanoseconds isn't > really the issue here. Most of the pros and cons around implementing > direct support for slf4j in log4j aren't technical and we should at > least think through what they are and consider the tradeoffs. > > 2. We have had (nearly) zero input from users requesting direct > support > for slf4j. > > > Scott Deboy > Principal Engineer > COMOTIV SYSTEMS > 111 SW Columbia Street Ste. 950 > Portland, OR 97201 > Office: 503.224.7496 > Direct Line: 503.821.6482 > Cell: 503.997.1367 > Fax: 503.222.0185 > sde...@comotivsystems.com > www.comotivsystems.com > > > -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Friday, December 12, 2008 4:30 PM > To: Log4J Developers List > Subject: Re: [PROPOSAL] Implementing the SLF4J API directly > > > On Dec 12, 2008, at 10:47 AM, Scott Deboy wrote: > >> Why don't we post the pros and cons of implementing slf4j on our >> wiki. >> >> We should also solicit user feedback - I don't recall much/any log4j- >> user conversations regarding slf4j. >> >> Scott Deboy >> > > I'm not sure what the point in debating this more is. Let Ceki > implement what he wants to do in a sandbox or branch. It can then be > reviewed to see if it is appropriate for 1.2.x or needs to go to 2.0. > > Ralph > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > - > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org <>- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
I suppose that is fair. But I will tell you that I am biased. I use SLF4J. Right now I can't use log4j because it is missing features that Logback has. The primary reason I asked to be involved in Log4j 2.0 was so that I could address that. Obviously I haven't had the time to get started but I still intend to. Maybe that will be what I do over the Christmas holiday. So whether SLF4J is added to 1.2 doesn't really matter to me. Ralph On Dec 12, 2008, at 4:45 PM, Scott Deboy wrote: I had two points I was trying to make: 1. Whether or not the slf4j formatter is faster by x nanoseconds isn't really the issue here. Most of the pros and cons around implementing direct support for slf4j in log4j aren't technical and we should at least think through what they are and consider the tradeoffs. 2. We have had (nearly) zero input from users requesting direct support for slf4j. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 sde...@comotivsystems.com www.comotivsystems.com -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Friday, December 12, 2008 4:30 PM To: Log4J Developers List Subject: Re: [PROPOSAL] Implementing the SLF4J API directly On Dec 12, 2008, at 10:47 AM, Scott Deboy wrote: Why don't we post the pros and cons of implementing slf4j on our wiki. We should also solicit user feedback - I don't recall much/any log4j- user conversations regarding slf4j. Scott Deboy I'm not sure what the point in debating this more is. Let Ceki implement what he wants to do in a sandbox or branch. It can then be reviewed to see if it is appropriate for 1.2.x or needs to go to 2.0. Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
RE: [PROPOSAL] Implementing the SLF4J API directly
I had two points I was trying to make: 1. Whether or not the slf4j formatter is faster by x nanoseconds isn't really the issue here. Most of the pros and cons around implementing direct support for slf4j in log4j aren't technical and we should at least think through what they are and consider the tradeoffs. 2. We have had (nearly) zero input from users requesting direct support for slf4j. Scott Deboy Principal Engineer COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Office: 503.224.7496 Direct Line: 503.821.6482 Cell: 503.997.1367 Fax: 503.222.0185 sde...@comotivsystems.com www.comotivsystems.com -Original Message- From: Ralph Goers [mailto:ralph.go...@dslextreme.com] Sent: Friday, December 12, 2008 4:30 PM To: Log4J Developers List Subject: Re: [PROPOSAL] Implementing the SLF4J API directly On Dec 12, 2008, at 10:47 AM, Scott Deboy wrote: > Why don't we post the pros and cons of implementing slf4j on our wiki. > > We should also solicit user feedback - I don't recall much/any log4j- > user conversations regarding slf4j. > > Scott Deboy > I'm not sure what the point in debating this more is. Let Ceki implement what he wants to do in a sandbox or branch. It can then be reviewed to see if it is appropriate for 1.2.x or needs to go to 2.0. Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 12, 2008, at 10:47 AM, Scott Deboy wrote: Why don't we post the pros and cons of implementing slf4j on our wiki. We should also solicit user feedback - I don't recall much/any log4j- user conversations regarding slf4j. Scott Deboy I'm not sure what the point in debating this more is. Let Ceki implement what he wants to do in a sandbox or branch. It can then be reviewed to see if it is appropriate for 1.2.x or needs to go to 2.0. Ralph - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
RE: [PROPOSAL] Implementing the SLF4J API directly
Why don't we post the pros and cons of implementing slf4j on our wiki. We should also solicit user feedback - I don't recall much/any log4j-user conversations regarding slf4j. Scott Deboy -Original Message- From: Ceki Gulcu [mailto:c...@qos.ch] Sent: Friday, December 12, 2008 10:18 AM To: Log4J Developers List Subject: Re: [PROPOSAL] Implementing the SLF4J API directly Curt Arnold wrote: >> [1] http://bugzilla.slf4j.org/show_bug.cgi?id=116 > > Please use ASF resources for log4j related development. All development > needs to be done in public in community or it may need to be reviewed by > the Incubator PMC. The slf4j.org bugzilla URL was a reference used higher up in my message. Note the [1] preceding the URL. I am aware of the rules. -- Ceki Gülcü - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Curt Arnold wrote: [1] http://bugzilla.slf4j.org/show_bug.cgi?id=116 Please use ASF resources for log4j related development. All development needs to be done in public in community or it may need to be reviewed by the Incubator PMC. The slf4j.org bugzilla URL was a reference used higher up in my message. Note the [1] preceding the URL. I am aware of the rules. -- Ceki Gülcü - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 12, 2008, at 9:01 AM, Ceki Gulcu wrote: True. I'll get the ball rolling so that you will have code to look at. [1] http://bugzilla.slf4j.org/show_bug.cgi?id=116 Please use ASF resources for log4j related development. All development needs to be done in public in community or it may need to be reviewed by the Incubator PMC. - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 9th 2008 16:57 GMT Curt Arnold wrote:
> The supposed performance benefit of the SLF4J formatter over the
> java.text.MessageFormat only occurs when you compare the performance
> against naive use of java.text.MessageFormat. LogMF handles the
> simplest pattern specifications (those just involving {0}, {1}, etc)
> internally and only delegates to java.text.MessageFormat for more
> complex pattern specifications, resulting in equivalent performance to
> the SLF4J formatter on functionally equivalent format specifiers while
> still supporting the full java.text.MessageFormat capabilities.
On Dec 11, 2008, at 9:04 AM, Ceki Gulcu wrote:
> There is no point in digging into into the archives. Unless you can
> point to a mistake in the test case I provided yesterday, it
> irrefutably demonstrates that LogMF does not offer equivalent
> performance.
On Dec 11, 2008, at 9:04 AM, Curt Arnold wrote:
> You are using a private method in a totally artificial manner and no
> comparison with the overhead of creating a LoggingEvent etc. Maybe
> outside the context of a logging request the performance difference
> was significant, but the performance difference could be dwarfed by
> the expense of creating a LoggingEvent or some other fixed cost.
My use the format method (a private method) in LogMF is not "totally
artificial". It directly compares the LogMF formatter with the SLF4J
formatter, irrefutably demonstrating that the SLF4J formatter is 7.5
times faster than the LogMF formatter. It would have been nice for you
to acknowledge that fact. Instead, you are now arguing that the
performance difference does not matter. You write:
> I will explain why I've not been fully involved in this thread in very
> short order. Please realize that I spent a large amount of time on
> this list several years ago discussing with the community and provided
> many benchmarks at that time. I recall it did not show any detectable
> difference due to SLF4J-style format and MessageFormat in the context
> of either a trivial appender or a lower than threshold request. Maybe
> there very well could be a slight difference in performance of the
> formatter, but if it is dwarfed by other unavoidable costs (creation
> of a LoggingEvent for example), then the relative difference would
> never be noticed.
Instead of comparing the formatting methods, we can compare the time
it takes to log into a file. I am not talking about NullAppender but a
bona fide FileAppender. Here is the code:
package test;
import org.apache.log4j.LogMF;
import org.apache.log4j.Logger;
import org.junit.Test;
import org.slf4j.LoggerFactory;
public class YTest {
static int LEN = 10;
final static String MSG = "Hello Hello Hello Hello {}";
final static String MSG_2 = "Hello Hello Hello Hello {0}";
Integer x = new Integer(1);
Logger log4jLogger = Logger.getLogger(YTest.class);
org.slf4j.Logger slf4jLogger = LoggerFactory.getLogger(YTest.class);
@Test
public void testLogMF() {
for (int i = 0; i < LEN; i++) {
LogMF.debug(log4jLogger, MSG_2, x);
}
long start = System.nanoTime();
for (int i = 0; i < LEN; i++) {
LogMF.debug(log4jLogger, MSG_2, x);
}
long end = System.nanoTime();
System.out.println("LogMF avg=" + (end - start) / LEN);
}
@Test
public void testSLF4J() {
for (int i = 0; i < LEN; i++) {
slf4jLogger.debug(MSG, x);
}
long start = System.nanoTime();
for (int i = 0; i < LEN; i++) {
slf4jLogger.debug(MSG, x);
}
long end = System.nanoTime();
System.out.println("SLF4J avg=" + (end - start) / LEN);
}
}
Here is the log4j.properties configuration file:
log4j.rootLogger=debug, FILE
log4j.appender.FILE=org.apache.log4j.FileAppender
log4j.appender.FILE.File=ytest.log
log4j.appender.FILE.BufferedIO=true
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d %p %c - %m%n
To run this test, in addition to junit4.jar, you need to have
slf4j-api.jar, apache-log4j-extras-1.1-SNAPSHOT.jar and log4j.jar on
your class path.
On my machine the output is:
LogMF avg=15251
SLF4J avg=4964
This shows that an enabled logging statement runs three times faster
when logging via SLF4J than when logging through LogMF, with log4j as
the underlying logging framework. Not only is the SLF4J formatter
faster, it makes a "noticeable" difference when the logs are actually
written to destination.
In conclusion, assuming the last two tests I provided are error-free,
they establish that not only the SLF4J formatter is faster, this
difference is clearly noticeable by the end-user.
> There are many features that java.text.MessageFormat has that the
> SLF4J formatter does not have. Even if there is a substantial
> performance difference, there may be cases where you would want to use
> MessageFormat or java.util.Formatter in spite of performance
> differences. The LogMF and LogSF approach allows users to pick which
> formatter b
Re: [PROPOSAL] Implementing the SLF4J API directly
Thorbjørn Ravn Andersen wrote: There is the minor thing that you are not using the result returned by the format routines. Hence the JIT _MAY_ have done optimization tricks influencing the numbers you see. Also you have not shown that the output numbers are statistically representative (i.e. close to the mean of several runs) and how the numbers are if you test slf4J before log4mf (as HotSpot optimizations may kick in while testLogMF is being run). Is the resolution of your nanotime function high enough that the differences over a single format()-invocation is usable for summarizing, i.e. can you inject the measurement code in a real life scenario? I have ran the tests at least three or four times. The results are stable which imho obviates the need to compute averages of the runs. Modifying the test to collect the results in a public field of the test does not modify the results but prevents the JIT from short circuiting the method invocation. Inversing the order of the tests or disabling one test and then the order does not change the results either. (I have actually performed all of the above checks.) Moreover, as you point out, the nano time function may be playing tricks on me, but if it is, it is doing so very consistently. :-) When I say irrefutable proof, I mean within the context of log4j and this discussion. If human lives were at stake, then it would be wise to repeat the tests on at least 5 other machines running different operating systems and different JVMs by different providers (IBM, Sun, Bea). Asking independent parties to repeat the experiment would also be warranted. The test I provided directly compares the formatting functions of SLF4J and LogMF. One can argue that the performance difference does not matter, as Curt has. However, one can no longer argue that there is no performance difference. Nevertheless, I agree with you that care is required when dealing with performance measurements which can be sometimes misleading. In that spirit, I encourage you to repeat the experiment and share your results. -- Ceki Gülcü - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 11-12-2008 16:04: There is no point in digging into into the archives. Unless you can point to a mistake in the test case I provided yesterday, it irrefutably demonstrates that LogMF does not offer equivalent performance. There is the minor thing that you are not using the result returned by the format routines. Hence the JIT _MAY_ have done optimization tricks influencing the numbers you see. Also you have not shown that the output numbers are statistically representative (i.e. close to the mean of several runs) and how the numbers are if you test slf4J before log4mf (as HotSpot optimizations may kick in while testLogMF is being run). Is the resolution of your nanotime function high enough that the differences over a single format()-invocation is usable for summarizing, i.e. can you inject the measurement code in a real life scenario? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 11, 2008, at 9:04 AM, Ceki Gulcu wrote:
On Dec 9th 2008 16:57 GMT Curt Arnold wrote:
> The supposed performance benefit of the SLF4J formatter over the
> java.text.MessageFormat only occurs when you compare the performance
> against naive use of java.text.MessageFormat. LogMF handles the
> simplest pattern specifications (those just involving {0}, {1}, etc)
> internally and only delegates to java.text.MessageFormat for more
> complex pattern specifications, resulting in equivalent
performance to
> the SLF4J formatter on functionally equivalent format specifiers
while
> still supporting the full java.text.MessageFormat capabilities.
On Dec 11th 2008 08:21 GMT Curt Arnold wrote:
As I remember, my benchmarks were very, very low overhead logging
calls (NullAppender or the like) or less than threshold logging
calls and the performance between the formatters was totally lost
in the NullAppender overhead. It was several years ago, so I'll
have to dig in the archives.
There is no point in digging into into the archives. Unless you can
point to a mistake in the test case I provided yesterday, it
irrefutably demonstrates that LogMF does not offer equivalent
performance.
You are using a private method in a totally artificial manner and no
comparison with the overhead of creating a LoggingEvent etc. Maybe
outside the context of a logging request the performance difference
was significant, but the performance difference could be dwarfed by
the expense of creating a LoggingEvent or some other fixed cost.
Recognizing performance advantage of the SLF4J formatter would have
been a welcome change. At the very least you should stop referring to
the "supposed" or "alleged" performance benefits of the SLF4J
formatter. Moreover, in the future, you should refrain from making
incorrect statements with such self-confidence and certainty and later
weasel yourself out of them by minimizing their importance.
I will explain why I've not been fully involved in this thread in very
short order. Please realize that I spent a large amount of time on
this list several years ago discussing with the community and provided
many benchmarks at that time. I recall it did not show any detectable
difference due to SLF4J-style format and MessageFormat in the context
of either a trivial appender or a lower than threshold request. Maybe
there very well could be a slight difference in performance of the
formatter, but if it is dwarfed by other unavoidable costs (creation
of a LoggingEvent for example), then the relative difference would
never be noticed.
There are many features that java.text.MessageFormat has that the
SLF4J formatter does not have. Even if there is a substantial
performance difference, there may be cases where you would want to use
MessageFormat or java.util.Formatter in spite of performance
differences. The LogMF and LogSF approach allows users to pick which
formatter best suits their needs. The SLF4J approach enforces a
choice of a particular formatter over any other formatter.
As for Jorg who does like message formatting, he is obviously entitled
to his opinion. However, as log4j committers, out job is to respond to
user demand. While several years ago one could reasonably argue that
SLF4J was not a mature and stable API, that argument is no longer
valid. Not only is the SLF4J API stable and mature, it is also very
popular. By adopting the SLF4J API natively, the log4j community would
do the larger java developer community an immense service by
disambiguating java logging. I don't think that half-hearted attempts
such as the "extras companion" help, on the contrary. Java logging
does not need more choice. On the contrary, it needs consolidation.
The Apache Software Foundation does not control the SLF4J project, but
since when the ASF is about control? There are many Apache projects
which implement specifications drafted outside Apache.
The Apache Software Foundation is about community and collaborative
development first. Projects that ignore community and collaboration
are either chastised by the board or shown the door.
There is a substantial community that depends on log4j 1.x remaining
100% compatible with their existing code that used log4j 1.x features
in the expected and normal way. It is a disservice to them to release
any log4j 1.x that breaks their perfectly valid app. Several years
ago there was not an identified way to directly support SLF4J without
breaking compatibility with any app that used a non-String message and
without making a maintenance release add a dependency on an alpha or
beta jar. Maybe your new proposal addresses the compatibility issue
and SLF4J is fixed, but there has not been any time to prepare an
exploratory project in the sandbox to confirm your suggested approach
and to evaluate the consequences.
In my earlier discussion about the ASF and log4j brand, my intention
was no
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 9th 2008 16:57 GMT Curt Arnold wrote:
> The supposed performance benefit of the SLF4J formatter over the
> java.text.MessageFormat only occurs when you compare the performance
> against naive use of java.text.MessageFormat. LogMF handles the
> simplest pattern specifications (those just involving {0}, {1}, etc)
> internally and only delegates to java.text.MessageFormat for more
> complex pattern specifications, resulting in equivalent performance to
> the SLF4J formatter on functionally equivalent format specifiers while
> still supporting the full java.text.MessageFormat capabilities.
On Dec 11th 2008 08:21 GMT Curt Arnold wrote:
As I remember, my benchmarks were very, very low overhead logging calls
(NullAppender or the like) or less than threshold logging calls and the
performance between the formatters was totally lost in the NullAppender
overhead. It was several years ago, so I'll have to dig in the archives.
There is no point in digging into into the archives. Unless you can
point to a mistake in the test case I provided yesterday, it
irrefutably demonstrates that LogMF does not offer equivalent
performance.
Recognizing performance advantage of the SLF4J formatter would have
been a welcome change. At the very least you should stop referring to
the "supposed" or "alleged" performance benefits of the SLF4J
formatter. Moreover, in the future, you should refrain from making
incorrect statements with such self-confidence and certainty and later
weasel yourself out of them by minimizing their importance.
As for Jorg who does like message formatting, he is obviously entitled
to his opinion. However, as log4j committers, out job is to respond to
user demand. While several years ago one could reasonably argue that
SLF4J was not a mature and stable API, that argument is no longer
valid. Not only is the SLF4J API stable and mature, it is also very
popular. By adopting the SLF4J API natively, the log4j community would
do the larger java developer community an immense service by
disambiguating java logging. I don't think that half-hearted attempts
such as the "extras companion" help, on the contrary. Java logging
does not need more choice. On the contrary, it needs consolidation.
The Apache Software Foundation does not control the SLF4J project, but
since when the ASF is about control? There are many Apache projects
which implement specifications drafted outside Apache.
So, what is in it for log4j? First, it would give new life to the
project. Second, it would make log4j an easier sell. Some developers,
albeit not all, will say: "let use log4j for logging instead of jul
because it natively implements SLF4J. We can later switch if we want
to".
So, what is in it for SLF4J? SLF4J would be endorsed by log4j which is
certainly good for SLF4J. However, it is also good for log4j. Some
developers, albeit not all, will say: "should we use jul, log4j or
logback as the underlying SLF4J implementation? Let us use log4j
because it implements SLF4J natively."
Sound far-fetched? Think 3 years ahead and pretend 50% of all OSS
projects already use SLF4J for logging. I believe that is going to
happen whether log4j implements SLF4J or not. If you think that is a
possibility, then implementing the SLF4J API today makes sense.
Enough said.
--
Ceki Gülcü
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 10, 2008, at 11:36 AM, Ceki Gulcu wrote:
Curt Arnold wrote:
The supposed performance benefit of the SLF4J formatter over the
java.text.MessageFormat only occurs when you compare the
performance against naive use of java.text.MessageFormat. LogMF
handles the simplest pattern specifications (those just involving
{0}, {1}, etc) internally and only delegates to
java.text.MessageFormat for more complex pattern specifications,
resulting in equivalent performance to the SLF4J formatter on
functionally equivalent format specifiers while still supporting
the full java.text.MessageFormat capabilities.
For a short message of 25 letters, on my machine, LogMF.format(String,
Object) takes 7.5 microseconds, while the SLF4J formatter takes 1
microsecond. Thus, there is a ratio of 7.5 to 1 in performance.
Given that it takes 5 to 10 microseconds to write a logging event to
file, the LogMF overhead is significant.
To repeat the experiment:
> svn co http://svn.apache.org/repos/asf/logging/log4j/companions/extras/trunk/
extras
> modify LogMF.format(String pattern, Object arg0) method as public
instead of private
> mvn package -Dmaven.test.skip=true
> Add slf4j-api-1.5.6.jar and apache-log4j-extras-1.1-SNAPSHOT.jar
(that you just built) to you class path.
> Run the following unit test
package test;
import org.apache.log4j.LogMF;
import org.junit.Test;
import org.slf4j.helpers.MessageFormatter;
public class XTest {
static int LEN = 10;
final static String MSG = "Hello Hello Hello Hello {}";
final static String MSG_2 = "Hello Hello Hello Hello {0}";
Integer x = new Integer(1);
@Test
public void testLogMF() {
for(int i = 0; i < LEN; i++ ){
LogMF.format(MSG_2, x);
}
long start = System.nanoTime();
for(int i = 0; i < LEN; i++ ){
LogMF.format(MSG_2, x);
}
long end = System.nanoTime();
System.out.println("LogMF avg="+ (end-start)/LEN);
}
@Test
public void testSLF4J() {
for(int i = 0; i < LEN; i++ ){
MessageFormatter.format(MSG, x);
}
long start = System.nanoTime();
for(int i = 0; i < LEN; i++ ){
MessageFormatter.format(MSG, x);
}
long end = System.nanoTime();
System.out.println("SLF4J avg="+ (end-start)/LEN);
}
On my machine the output is:
LogMF avg=7568
SLF4J avg=1021
Thus, contrary to your claim, LogMF does *not* offer equivalent
performance to SLF4J's formatter.
As I remember, my benchmarks were very, very low overhead logging
calls (NullAppender or the like) or less than threshold logging calls
and the performance between the formatters was totally lost in the
NullAppender overhead. It was several years ago, so I'll have to dig
in the archives.
The SLF4J formatting style, altough not the same as the JDK's, is
easier to type (try it) and less error prone (you can't get the
numbers wrong because there are none). More importantly, SLF4J users
love it.
The numbers are very useful if you are dealing with
internationalization (as the previous link which was almost one of the
first feedback items on slf4j-dev). Maybe some users love no indexes,
others find them useful.
Instead of trying to re-invent the wheel, we, as log4j developers,
would do the java developer community a favor by adopting SLF4J, a
popular and stable API. As mentioned on several occasions by now,
there is also a way to conserve 100% compatibility for existing
log4j clients.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Curt Arnold wrote:
The supposed performance benefit of the SLF4J formatter over the
java.text.MessageFormat only occurs when you compare the performance
against naive use of java.text.MessageFormat. LogMF handles the
simplest pattern specifications (those just involving {0}, {1}, etc)
internally and only delegates to java.text.MessageFormat for more
complex pattern specifications, resulting in equivalent performance to
the SLF4J formatter on functionally equivalent format specifiers while
still supporting the full java.text.MessageFormat capabilities.
For a short message of 25 letters, on my machine, LogMF.format(String,
Object) takes 7.5 microseconds, while the SLF4J formatter takes 1
microsecond. Thus, there is a ratio of 7.5 to 1 in performance.
Given that it takes 5 to 10 microseconds to write a logging event to
file, the LogMF overhead is significant.
To repeat the experiment:
> svn co http://svn.apache.org/repos/asf/logging/log4j/companions/extras/trunk/
extras
> modify LogMF.format(String pattern, Object arg0) method as public instead of
private
> mvn package -Dmaven.test.skip=true
> Add slf4j-api-1.5.6.jar and apache-log4j-extras-1.1-SNAPSHOT.jar (that you
just built) to you class path.
> Run the following unit test
package test;
import org.apache.log4j.LogMF;
import org.junit.Test;
import org.slf4j.helpers.MessageFormatter;
public class XTest {
static int LEN = 10;
final static String MSG = "Hello Hello Hello Hello {}";
final static String MSG_2 = "Hello Hello Hello Hello {0}";
Integer x = new Integer(1);
@Test
public void testLogMF() {
for(int i = 0; i < LEN; i++ ){
LogMF.format(MSG_2, x);
}
long start = System.nanoTime();
for(int i = 0; i < LEN; i++ ){
LogMF.format(MSG_2, x);
}
long end = System.nanoTime();
System.out.println("LogMF avg="+ (end-start)/LEN);
}
@Test
public void testSLF4J() {
for(int i = 0; i < LEN; i++ ){
MessageFormatter.format(MSG, x);
}
long start = System.nanoTime();
for(int i = 0; i < LEN; i++ ){
MessageFormatter.format(MSG, x);
}
long end = System.nanoTime();
System.out.println("SLF4J avg="+ (end-start)/LEN);
}
On my machine the output is:
LogMF avg=7568
SLF4J avg=1021
Thus, contrary to your claim, LogMF does *not* offer equivalent performance to
SLF4J's formatter.
The SLF4J formatting style, altough not the same as the JDK's, is easier to type
(try it) and less error prone (you can't get the numbers wrong because there are
none). More importantly, SLF4J users love it.
Instead of trying to re-invent the wheel, we, as log4j developers, would do the
java developer community a favor by adopting SLF4J, a popular and stable API. As
mentioned on several occasions by now, there is also a way to conserve 100%
compatibility for existing log4j clients.
--
Ceki Gülcü
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 9, 2008, at 4:58 AM, Thorbjørn Ravn Andersen wrote:
There was a request recently to make the argument replacement
mechanism more powerful in either slf4j or logback (cannot remember)
where Ceki mentioned that one of the major benefits of the {}-
approach was that it was measurably faster than the StringFormatter
in Java.
For this particular purpose I suggest that the fastest approach is
chosen as it will apply to all events actually processed. Would
lifting the slf4j code into log4j be an option - I believe that the
license allows it.
There are two formatters in the Java API, java.text.MessageFormat
(since JDK 1) and java.util.Formatter (since JDK 5). The SLF4J format
specifier resembles, but is incompatible with, the format specifier of
java.text.MessageFormat.
Actually the SLF4J formatting code (as far as I can tell) was
originally written as part of log4j 1.3 and already is used in LogSF
in the extras companion. LogMF provides the same services but uses
java.text.MessageFormat format specifiers. While these were in the
sandbox, there was a LogF which provided the same services using the
java.util.Formatter, however their wasn't sufficient demand to polish
that up for release. Still very doable.
LogMF and LogSF provided highly optimized message parameterization
compatible with log4j 1.2.8 and later. Keeping message formatting
distinct from the logger class allows supporting different formatters.
The supposed performance benefit of the SLF4J formatter over the
java.text.MessageFormat only occurs when you compare the performance
against naive use of java.text.MessageFormat. LogMF handles the
simplest pattern specifications (those just involving {0}, {1}, etc)
internally and only delegates to java.text.MessageFormat for more
complex pattern specifications, resulting in equivalent performance to
the SLF4J formatter on functionally equivalent format specifiers while
still supporting the full java.text.MessageFormat capabilities.
This very early thread on slf4j-dev (http://marc.info/?l=slf4j-dev&m=112327572703543&w=2
) discussed the potential use of java.text.MessageFormat pattern
specifiers long before SLF4J was frozen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Paul Smith skrev den 09-12-2008 02:46:
private static String getFormattedMessage(String message,
Object... args) {
String formattedMessage = message;
if (args != null && args.length > 0) {
formattedMessage = String.format(message, args);
}
return formattedMessage;
}
..
Then the code is changed to:
LogUtils.debug(LOG, "Hello %s, your age is %d", name, age);
Now, that bypasses slf4j completely, and maintains source &
binary compatibly, and can easily be migrated to.
There was a request recently to make the argument replacement mechanism
more powerful in either slf4j or logback (cannot remember) where Ceki
mentioned that one of the major benefits of the {}-approach was that it
was measurably faster than the StringFormatter in Java.
For this particular purpose I suggest that the fastest approach is
chosen as it will apply to all events actually processed. Would
lifting the slf4j code into log4j be an option - I believe that the
license allows it.
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Paul Smith wrote:
If logger implements org.slf4j.Logger, then one can write
String name = "Scott";
logger.debug("Hello Scott");
logger.debug("Hello {}", name);
Both log statements will print as "Hello Scott". However, the latter
log statement will contain 'name' as a parameter. The SLF4J
implementation can choose to preserve or to discard this parameter in
the LoggingEvent.
SLF4J allows for 0,1,2 or an array of parameters. Thus, you can write
Map aMap = ...;
List aList = ...;
logger.debug("Hello", new Object[]{new Integer(37), aMap, aList});
First off, I've come back from some leave, and prior to that was
extremely overloaded at work, so my attention to detail on this thread
is limited.
Am I correct in distilling that the crux of the _driver_ to do this is
to support the above, and only that feature? This is 'nice' but really
not that high a priority I would have thought.. Given the vast majority
of people are on Java5+ platforms, a source and binary compatible way is
to introduce a simple 'log4j-java5plus' extension jar that has something
like this:
Support for parameterized logging is helpful. However, the main impetus is to
converge on a logging API for benefit of the java community. The benefit for
log4j may not be obvious at first, but the fact that it natively implements
SLF4J will enhance log4j's stature as well. This may be doubtful coming from me,
the author of SLF4J, but also log4j. Nevertheless, if you stop and think for a
second, it makes sense. My proposal is not only about log4j but about logging in
java. As log4j committer, here is your chance to shape the future of java
logging in a constructive way.
Of course, there is the temptation to believe that log4j is such a grand name
that it does need to adapt to changing circumstances. Don't succumb to that.
public class LogUtils {
..
public static void debug(Logger log, String message, Object... args) {
if (!log.isDebugEnabled()) {
return;
}
log.debug(getFormattedMessage(message, args));
}
..
private static String getFormattedMessage(String message, Object...
args) {
String formattedMessage = message;
if (args != null && args.length > 0) {
formattedMessage = String.format(message, args);
}
return formattedMessage;
}
..
Then the code is changed to:
LogUtils.debug(LOG, "Hello %s, your age is %d", name, age);
SLF4J's message formatting mechanism is extremely simple and very fast. It is
also very convenient, considering the most common cases. Your suggestion, offers
more flexibility and power, but which is not needed under most circumstances.
Now, that bypasses slf4j completely, and maintains source &
binary compatibly, and can easily be migrated to. My point is not to
suggest log4j introduce the above, or to dissuade from considering slf4j
integration more generally, but if the above feature is it... it really
doesn't seem like a massive driver that breaks binary compatibility and
possibly alienate a whole bunch of people (which it could, and that
could badly tarnish the log4j 'brand' as it were).
Quoting LOG4J2-27:
There is actually a way to maintain 100% source code compatibility. The
org.apache.log4j.Logger/Category classes would retain their existing method
signatures but would delegate to org.apache.log4j.impl.Logger class which would
implement the org.slf4j.Logger interface. This is feasible as demonstrated by
the log4j-over-slf4j module in SLF4J. See
http://slf4j.org/legacy.html#log4j-over-slf4j
Clients wishing to use the existing log4j classes could continue to do so. Those
wishing to standardize on the SLF4J API could do so as well. Direct use of
org.apache.log4j.impl.Logger would technically be possible but discouraged.
So I'm not in favour of rushing any decision at all.
The SLF4J debate has been ongoing for several years. Now that it has established
itself as a credible API, it is time to reconsider the question under new light.
Paul
--
Ceki Gülcü
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
If logger implements org.slf4j.Logger, then one can write
String name = "Scott";
logger.debug("Hello Scott");
logger.debug("Hello {}", name);
Both log statements will print as "Hello Scott". However, the latter
log statement will contain 'name' as a parameter. The SLF4J
implementation can choose to preserve or to discard this parameter in
the LoggingEvent.
SLF4J allows for 0,1,2 or an array of parameters. Thus, you can write
Map aMap = ...;
List aList = ...;
logger.debug("Hello", new Object[]{new Integer(37), aMap, aList});
First off, I've come back from some leave, and prior to that was
extremely overloaded at work, so my attention to detail on this thread
is limited.
Am I correct in distilling that the crux of the _driver_ to do this is
to support the above, and only that feature? This is 'nice' but really
not that high a priority I would have thought.. Given the vast
majority of people are on Java5+ platforms, a source and binary
compatible way is to introduce a simple 'log4j-java5plus' extension
jar that has something like this:
public class LogUtils {
..
public static void debug(Logger log, String message, Object...
args) {
if (!log.isDebugEnabled()) {
return;
}
log.debug(getFormattedMessage(message, args));
}
..
private static String getFormattedMessage(String message,
Object... args) {
String formattedMessage = message;
if (args != null && args.length > 0) {
formattedMessage = String.format(message, args);
}
return formattedMessage;
}
..
Then the code is changed to:
LogUtils.debug(LOG, "Hello %s, your age is %d", name, age);
Now, that bypasses slf4j completely, and maintains source & binary
compatibly, and can easily be migrated to. My point is not to suggest
log4j introduce the above, or to dissuade from considering slf4j
integration more generally, but if the above feature is it... it
really doesn't seem like a massive driver that breaks binary
compatibility and possibly alienate a whole bunch of people (which it
could, and that could badly tarnish the log4j 'brand' as it were).
So I'm not in favour of rushing any decision at all.
Paul
Re: [PROPOSAL] Implementing the SLF4J API directly
On 09/12/2008, at 2:27 AM, saimen54 wrote: Jacob Kjome wrote: http://logging.apache.org/log4j/companions/component/index.html http://logging.apache.org/log4j/companions/extras/index.html http://logging.apache.org/log4j/companions/receivers/index.html http://logging.apache.org/log4j/companions/zeroconf/index.html And is there any chance that component, receivers and zeroconf get jar'ed in this decade? touché! :) Once Curt is back on track and we can discuss a release plan for 1.2.16 (personally I vote for 'stop & release now'), we can then move to these, but yes, your point is well made, this has been a long time in coming. Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Thorbjørn Ravn Andersen wrote: I agree that the log4j is currently in a very uninteresting place developmentwise, but so be it. As long as there hasn't been a consensus on where to go from here - and WHY - it is hard to initiate a coordinated development effort. There does not need to be a need for a coordinated developerment effort. A majority of log4j committers have to agree that adopting the SLF4J API is "the right thing to do" (TM). There is no technical reasons for a lot of the things we do, but we do them anyway for reasons beyond the technical. There are no technical reasons why log4j is in such a vegatative state. It just is. I am proposing a way to restart the engine and deliver something useful to the community in a reasonable amount of time. I think, however, that the Apache brand is extremely strong in the development community, as it has proven to stay around and has enough "mass" to ensure that projects stay maintained (and if not, that they are appropriately taken care of). You yourself know how strong the log4j brand is amonst developers, and I believe there was a reason that you chose back then to move it to Apache. It is a top level project, which is an accomplishment in itself. Kudos for that. Back in early 2001, log4j integrated Apache on invitation. It was just a friendly place to do development, a bit like codehaus today. There was no Apache incubator, and Apache HTPD was *the* project, everything else was new and experimental. Java projects at Apache were just starting to emerge. There was no Tomcat and no Struts. People did not join Apache for the brand name, because there was none to speak of. I am not poohing your proposal, I am wondering what is going on here. Would you care to explain why this suddenly is so important, if the Apache and log4j brands are unimportant? Brand names are important but at the end of the day, you have to deliver something useful to users. Users would benefit from having log4j integrated with SLF4J. There is nothing urgent about my proposal but I also would not want it stalled until 2020. -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Jacob Kjome wrote: > > http://logging.apache.org/log4j/companions/component/index.html > http://logging.apache.org/log4j/companions/extras/index.html > http://logging.apache.org/log4j/companions/receivers/index.html > http://logging.apache.org/log4j/companions/zeroconf/index.html > And is there any chance that component, receivers and zeroconf get jar'ed in this decade? Regards, Simon -- View this message in context: http://www.nabble.com/-PROPOSAL--Implementing-the-SLF4J-API-directly-tp20811383p20897405.html Sent from the Log4j - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
On Mon, 08 Dec 2008 10:06:44 +0100 Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote: Other projects have created extra packages containing such auxillary classes to avoid breaking things in the core package. The reason must be another :) ...and we have this. See... http://logging.apache.org/log4j/companions/component/index.html http://logging.apache.org/log4j/companions/extras/index.html http://logging.apache.org/log4j/companions/receivers/index.html http://logging.apache.org/log4j/companions/zeroconf/index.html http://svn.apache.org/viewvc/logging/sandbox/ http://svn.apache.org/viewvc/logging/sandbox/jul-to-log4j-bridge/ Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 08-12-2008 12:41: Thorbjørn Ravn Andersen wrote: I believe that Curt Arnold may be somewhat right in that this is a matter of Apache endorsement. This is purely guesswork. I still think that log4j should have a "Best practices" list, where the "use slf4j framework" should be on the list for backend independence, to inform the users as early as possible. Sigh. My proposal is a wake up call for log4j. The project can go back to slumber or come back to life by providing a valuable new feature to the java developer community. The problem with your proposal is that there is no pressing NEED for doing so. You have yourself provided the library that removed that need! Frankly I see no technical reason for your proposal - the graph you showed was a bit ugly - but not extremely so. Things converged nicely at the slf4j level, which was your intend all along, and which has been very successful. I agree that the log4j is currently in a very uninteresting place developmentwise, but so be it. As long as there hasn't been a consensus on where to go from here - and WHY - it is hard to initiate a coordinated development effort. Poohing my proposal under the pretext that it is a grab at Apache brand is extremely offensive. A little modesty regarding the importance of the Apache or log4j brands, would be a welcome change. As I am not involved with Apache in any other way than being a user of the products, and spent some time reporting bugs here and there, I believe I can say that I do not have any personal interest in "protecting" Apache or log4j.I believe that slf4j uses the right approach - load time binding - to select logger framework, but I am not singleminded about it. Everything I write is my personal opinion only. I think, however, that the Apache brand is extremely strong in the development community, as it has proven to stay around and has enough "mass" to ensure that projects stay maintained (and if not, that they are appropriately taken care of). You yourself know how strong the log4j brand is amonst developers, and I believe there was a reason that you chose back then to move it to Apache. It is a top level project, which is an accomplishment in itself. Kudos for that. I am not poohing your proposal, I am wondering what is going on here. Would you care to explain why this suddenly is so important, if the Apache and log4j brands are unimportant? And by the way: For those who don't know I am currently adding stuff to the slf4j-ext sub-project, and the logback-incubator but I am not more involved than that.I am a pragmatic who basically wants to reach a suitable solution which can live "forever" being maintained as that is traditionally how long code lives in our company. Apache has a very good record in this regard. You have a very valid point here. slf4j has not quite settled down yet - IMO - regarding features and releases so it would make perfect sense to keep log4j and slf4j distinct and disentangled. SLF4J has not settled down? What do you mean exactly? Do mean slf4j-ext (slf4j-extensions) or slf4j-api? I know - as I am providing code for it - that the slf4j-ext project is not settled down, but I was thinking of the API. I have not investigated closely, but since the version numbering is common for all of slf4j it is hard to identify how much or how little has changed and when. If there has been an announcement that slf4j-api is effectively frozen for the rest of the version 1.X's I've unfortunately missed it. (and please don't take any of this personally - rather, consider it an opportunity to respond instead of having to deal with what people THINK you mean :) -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Thorbjørn Ravn Andersen wrote: I believe that Curt Arnold may be somewhat right in that this is a matter of Apache endorsement. This is purely guesswork. I still think that log4j should have a "Best practices" list, where the "use slf4j framework" should be on the list for backend independence, to inform the users as early as possible. Sigh. My proposal is a wake up call for log4j. The project can go back to slumber or come back to life by providing a valuable new feature to the java developer community. Poohing my proposal under the pretext that it is a grab at Apache brand is extremely offensive. A little modesty regarding the importance of the Apache or log4j brands, would be a welcome change. You have a very valid point here. slf4j has not quite settled down yet - IMO - regarding features and releases so it would make perfect sense to keep log4j and slf4j distinct and disentangled. SLF4J has not settled down? What do you mean exactly? Do mean slf4j-ext (slf4j-extensions) or slf4j-api? -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Jacob Kjome skrev den 07-12-2008 06:04: On 12/6/2008 6:27 AM, Thorbjørn Ravn Andersen wrote: I believe that the positive in decoupling the logging implementation from the application will vastly overshadow any inconvinience in this regard. Most if not all of the work has been done in the slf4j project. Right. "Most if not all the work has been done". What is left? SLF4J has succeeded in its aim. Congratulations! And I'm not being facetious here. So, what exactly is the impetus to to modify Log4j 1.2 when existing SLF4J binders work well with it? I believe that Curt Arnold may be somewhat right in that this is a matter of Apache endorsement. This is purely guesswork. I still think that log4j should have a "Best practices" list, where the "use slf4j framework" should be on the list for backend independence, to inform the users as early as possible. Also, it seems to me that there is a clear advantage to the SLF4J project in maintaining control of its own development. If there's some fundamental fix that needs to be done to all binders it can be done and released quickly; entirely under the control of one project. Why move part of this control out to external projects? What is the advantage of it? Wouldn't that necessitate Log4j to coordinate its release cycles with SLF4J to a certain extent? Such a burden seems totally unnecessary as they can and have lived happily apart up to now. You have a very valid point here. slf4j has not quite settled down yet - IMO - regarding features and releases so it would make perfect sense to keep log4j and slf4j distinct and disentangled. I'm not sure about this whole "JUL has won the API war" thing? I guess I'd have to hear more from Curt about why he believes this? I've never even considered using JUL, but maybe that's just me? j.u.l has a few advantages over log4j, one of them being it works without a configuration file :) However, the question of why Log4j has not provided adapters for JUL in the 1.2.xx codebase is probably because it's somewhat of a dead end, development-wise. It is in maintenance mode. It generally works well, but there are fundamental issues (threading) that can't be fixed without breaking compatibility. So, changes are limited to those that preserve compatibility. The upside is that existing users who have written custom extensions can upgrade and pick up fixes without having to worry about breakage. The downside is that the motivation to innovate remains in hibernation until someone gets cracking on Log4j 2.0. I, for one, seem to have less and less time for this as the years go by; sad but true. Other projects have created extra packages containing such auxillary classes to avoid breaking things in the core package. The reason must be another :) Are you *ABSOLUTELY* certain you want to bring in politics in this technical issue? In my opinion it will only mudden the waters! I don't necessarily condone it, but I understand where it comes from. And unless you followed Log4j-1.3/nLog4j/UGLI experience a few years back, you probably won't understand. All I can say is that there's a bit of Dejavu going on here I did not follow the experience a few years back, so I don't understand much. I do understand, however, that apparently this controversy caused a project to fork, so it must have been bad. "I propose that log4j implement the SLF4J API directly. This can be done in the next version of log4j, say 1.3 or 2.0." New versions which break stuff have a tendency to gain less adoption from users. Right now it is a bit vague talking about the next version of log4j, as not much is happening which could warrant a new release.It appears to me that most of the logging development taking place at the moment happens in logback. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Here is a brain dump, in the form of a QA list, in response to Jake's last message and the questions raised by him. Q: What is the impetus to modify log4j, or what is to be gained by log4j directly implementing SLF4J? A: The gain is standardization. When projects debate about which logging API they should use, while often times they decide upon SLF4J, it just takes too much effort and time to reach that conclusion. It is just a big waste of time for everyone involved. So the question is not "what is in it for log4j, but what is in it for the wider java developer community". Q: Wouldn't implementing the SLF4J API create an undesirable coupling between SLF4J and log4j? Yes, log4j will be expected to follow the SLF4J API. This indeed creates a coupling. However, given that the SLF4J API is very stable, the effects on log4j are likely to be manageable. Moreover, the logback project which natively implements the SLF4J API keeps up with SLF4J without any difficulty. The SLF4J FAQ has a related entry: http://www.slf4j.org/faq.html#version_checks Q: What is manageable ease? A: Log4j version implementing in the SLF4J API, assuming it participates in SLF4J's version check mechanism, would need to set the SLF4J version against which it (log4j) was complied in a variable called REQUESTED_API_VERSION. This should not involve a few minutes of work every now and then. Q: But I don't have a few minutes. Would you do it? A: Yes, I would. Q: Should SLF4J be integrated into log4j 1.4 or 2.0? A: Given that 2.0 aims at a wider leap, 1.4 seems an easier target, especially one that can be arrived at within a reasonably short time frame. (In the remainder of the text, the SLF4J version of log4j will be called 1.4.) Q: Wouldn't implementing the SLF4J API break compatibility? A: Log4j could retain the existing signatures for the org.apache.log4j.Category/Logger classes. These classes would delegate their work to an instance of the org.apache.log4j.impl.Logger class which would be a native implementation of the org.slf4j.Logger interface. This approach would allow for existing client code to be compatible with log4j 1.4. (They would just need to replace log4j-1.2.x.jar with log4j-1.4.jar. Q: Wouldn't migrating to log4j 1.4 entail the inclusion of an additional jar? A: Yes, in addition to log4j-1.4.jar, clients would need to add slf4j-api.jar on their class path? Q: Are there other modifications required in log4j? A: No other modifications would be required in the log4j code base. However, the log4j documentation would need to be modified to refer to org.slf4j.Logger instead of org.apache.log4j.Logger. Q: What is the advantage for log4j users? A: Users of log4j 1.4, assuming they do not refer to the log4j API directly but to SLF4J instead, could switch to another logging framework such as j.u.l. or logback by simply replacing log4j-1.4.jar with another jar. However, issues related to logging configuration are not covered by the SLF4J API. Users would need to resort to ad hoc methods to migrate their configuration files. Q: Why not just use j.u.l? A: Despite the fact that jul is included in the JDK, it has not gained wide acceptance. Most java projects either use log4j, commons-logging or SLF4J as their logging API. Q: Considering a software project as a whole, isn't logging a secondary concern? A: Absolutely. Hence, this proposal, intended to make life easier for software developers, albeit a little harder on log4j developers. Q: What is in it for the log4j project? A: Besides helping fellow developers, when projects decide upon a logging API, log4j will be the logical candidate. Q: Isn't log4j the logical candidate already? A: Yes, it often is. Q: So, isn't doing nothing the easiest and smartest approach? A: Sigh. It usually is. Q: Why aren't you following your own advice? -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
On 12/6/2008 6:27 AM, Thorbjørn Ravn Andersen wrote: > > I believe that the positive in decoupling the logging implementation > from the application will vastly overshadow any inconvinience in this > regard. Most if not all of the work has been done in the slf4j project. Right. "Most if not all the work has been done". What is left? SLF4J has succeeded in its aim. Congratulations! And I'm not being facetious here. So, what exactly is the impetus to to modify Log4j 1.2 when existing SLF4J binders work well with it? Also, it seems to me that there is a clear advantage to the SLF4J project in maintaining control of its own development. If there's some fundamental fix that needs to be done to all binders it can be done and released quickly; entirely under the control of one project. Why move part of this control out to external projects? What is the advantage of it? Wouldn't that necessitate Log4j to coordinate its release cycles with SLF4J to a certain extent? Such a burden seems totally unnecessary as they can and have lived happily apart up to now. > >> However, I could see a significant political advantage to SLF4J to >> have an implicit endorsement from the ASF and in my mind that is what >> this proposal is about. In my mind, java.util.logging has already won >> the API standardization war years ago, but it has been mostly limited >> the available appenders and configurators. One of the design goals >> (https://issues.apache.org/jira/browse/LOG4J2-5) for log4j 2.0 is to >> have the back-end classes independent of the API, so that the bulk of >> log4j 2 is isolated from the client's API choice. > I find your statement quite interesting. > > If j.u.l won the standardization war, then how come that there has been > no adapter from log4j to j.u.l from this project? That would be the > perfect way to migrate to a standards based logging solution. > I'm not sure about this whole "JUL has won the API war" thing? I guess I'd have to hear more from Curt about why he believes this? I've never even considered using JUL, but maybe that's just me? However, the question of why Log4j has not provided adapters for JUL in the 1.2.xx codebase is probably because it's somewhat of a dead end, development-wise. It is in maintenance mode. It generally works well, but there are fundamental issues (threading) that can't be fixed without breaking compatibility. So, changes are limited to those that preserve compatibility. The upside is that existing users who have written custom extensions can upgrade and pick up fixes without having to worry about breakage. The downside is that the motivation to innovate remains in hibernation until someone gets cracking on Log4j 2.0. I, for one, seem to have less and less time for this as the years go by; sad but true. > Are you *ABSOLUTELY* certain you want to bring in politics in this > technical issue? In my opinion it will only mudden the waters! > I don't necessarily condone it, but I understand where it comes from. And unless you followed Log4j-1.3/nLog4j/UGLI experience a few years back, you probably won't understand. All I can say is that there's a bit of Dejavu going on here. BTW, notice that Curt did not say no. He said he wants to evaluate the proposal. I think that's reasonable and that demanding immediate consensus is not. I'd also like to hear some more convincing arguments from the SLF4J side about how this proposal provides real benefits over what exists today? See my questions above for more on that. Finally, let's not get lost in tangential issues and concentrate our attention on the original proposal... "I propose that log4j implement the SLF4J API directly. This can be done in the next version of log4j, say 1.3 or 2.0." I think consensus may be quite high if we're talking about Log4j 2.0, as it has already been planned that 2.0 will not be compatible with 1.2.xx. Though keep in mind that some have certain [re]designs in mind for 2.0. If Ceki's conception of 2.0 is simply 1.2.xx implementing the SLFJ, I'm not sure he will gain much traction? And, again, a convincing argument must be (and hasn't been) made as to the benefit of direct extension -vs- the existing model. Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
First let me say that I am in favor of log4j natively supporting the SLF4J API in 2.0. As I've also stated, I'd have no objection to using Logback as the foundation for 2.0 if we could. You've made it clear you are not interested in that. That is disappointing to me but such is life. I have no idea what went on before you went off and started logback and slf4j. I understand that you did a large part of the work, just as you are in those communities. However, I don't see how the tone of the message below is going to generate support from Curt and others. While it might be 100% true, more than likely it will just make them mad. I've seen the sentiment that log4j must remain 100% backward compatible. That will continue to be true in 1.2, but I can guarantee it won't be in 2.0, should it ever see the light of day. It simply can't in order to really support Java 5 and to fix some of the problems. As to whether a logging call should take an object or a String. SLF4J will actually take both. It is "cheating", but since all the parameters are Objects and they can be passed through the logging implementation I've used them to pass Objects to my custom appender without any problem. In Logback they are transient in the logging event object so they are lost once the event is serialized, but Log4j doesn't have to do that if they don't want to. Ralph On Dec 6, 2008, at 4:02 AM, Ceki Gulcu wrote: Curt Arnold wrote: As far as I can tell, there is no significant practical advantage to our user community to do a direct implementation of SLF4J in log4j over the facade implementation provided by slf4j.org. I have never seen a significant performance difference between the two approaches and a direct implementation has several strong negatives to the log4j community and users that have been previously discussed. However, I could see a significant political advantage to SLF4J to have an implicit endorsement from the ASF and in my mind that is what this proposal is about. In my mind, java.util.logging has already won the API standardization war years ago, but it has been mostly limited the available appenders and configurators. One of the design goals (https://issues.apache.org/jira/browse/LOG4J2-5) for log4j 2.0 is to have the back-end classes independent of the API, so that the bulk of log4j 2 is isolated from the client's API choice. I would like to remind you that there would not be a "log4j brand" without my work. Excluding chainsaw, I wrote 95% of log4j code and documentation and spent an order of magnitude more time on log4j than all the other contributors, including yourself, combined. Flaunting the log4j brand in my face is shameless. Since you arrived and filibustered the log4j project, it has gone nowhere. We used make log4j releases regularly. Now we are lucky if there is one release a year. We used to have a new committer once a semester. Log4j project was joined only by one new committer in the last 4 years, namely Ralh. All log4j comitters, excluding Ralph, but including you, have been nominated by me. Accusing me of wanting to get political advantage at the expense of Apache and the log4j brand, is shameless. If the current majority of log4j committers wish to continue the status quo, than that's that. However, I propose a path whereby log4j would converge on SLF4J, an established and popular API. This will make life easier for thousands of java developers. I wish more of them could speak up. If you really think that "java.util.logging has already won the API standardization war years ago" (quoting your own words) then none of this matters to you. By the way, how can you say such thing as logging PMC chair, especially since only a small minority of Java projects use j.u.l.? We used to have elections for PMC chair every year. There has not been any since you were elected in 2005. Why is that? Why hasn't log4j evolved in the last 4 years? Is it because you don't want it to evolve? -- Ceki Gülcü - 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: [PROPOSAL] Implementing the SLF4J API directly
Ceki Gulcu skrev den 04-12-2008 21:33: Curt has plainly expressed his feelings. What do others think? I think that the slf4j approach is the right way to select the logging framework, and it is the only implementation of this approach I am aware of. My personal "Best Practice" list has "use slf4j" high on the list. As slf4j is an open source project it is not a problem for users to use it and choose the backend they like, but an issue in whether log4j should acknowledge slf4j at all allowing users to avoid reinventing the wheel over and over again, when they find that they need to combine libraries which use java.util.logging and log4j with their own source. I strongly believe that either should the log4j project endorse the practice of using slf4j or provide its own implementation of "java.util.logging-over-log4j" bridging to give the users the best headstart in the world of large applications with lots of independent libraries. If this proprosal is rejected for any reason, the rejecters should at least initiate an alternative and reasonable solution to the problem of multiple logging frameworks in the same application, as this is a real issue encountered by real programmers. Personally I think that the least complex solution would be either to accept a donation of the log4j->slf4j bridge in the standard log4j distribution or go the whole way with Cekis suggestion. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Curt Arnold skrev den 04-12-2008 20:34: As far as I can tell, there is no significant practical advantage to our user community to do a direct implementation of SLF4J in log4j over the facade implementation provided by slf4j.org. I have never seen a significant performance difference between the two approaches and a direct implementation has several strong negatives to the log4j community and users that have been previously discussed. Simply the fact that it is impossible for programs using log4j or java util logging to switch between java.util.logging (the Sun standard) and log4j (the de-facto standard) should be enough to say that a solution must be found.The Commons logging project did not work well, and a revised version which do has not shown up. I believe that the positive in decoupling the logging implementation from the application will vastly overshadow any inconvinience in this regard. Most if not all of the work has been done in the slf4j project. However, I could see a significant political advantage to SLF4J to have an implicit endorsement from the ASF and in my mind that is what this proposal is about. In my mind, java.util.logging has already won the API standardization war years ago, but it has been mostly limited the available appenders and configurators. One of the design goals (https://issues.apache.org/jira/browse/LOG4J2-5) for log4j 2.0 is to have the back-end classes independent of the API, so that the bulk of log4j 2 is isolated from the client's API choice. I find your statement quite interesting. If j.u.l won the standardization war, then how come that there has been no adapter from log4j to j.u.l from this project? That would be the perfect way to migrate to a standards based logging solution. Are you *ABSOLUTELY* certain you want to bring in politics in this technical issue? In my opinion it will only mudden the waters! -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Curt Arnold wrote: As far as I can tell, there is no significant practical advantage to our user community to do a direct implementation of SLF4J in log4j over the facade implementation provided by slf4j.org. I have never seen a significant performance difference between the two approaches and a direct implementation has several strong negatives to the log4j community and users that have been previously discussed. However, I could see a significant political advantage to SLF4J to have an implicit endorsement from the ASF and in my mind that is what this proposal is about. In my mind, java.util.logging has already won the API standardization war years ago, but it has been mostly limited the available appenders and configurators. One of the design goals (https://issues.apache.org/jira/browse/LOG4J2-5) for log4j 2.0 is to have the back-end classes independent of the API, so that the bulk of log4j 2 is isolated from the client's API choice. I would like to remind you that there would not be a "log4j brand" without my work. Excluding chainsaw, I wrote 95% of log4j code and documentation and spent an order of magnitude more time on log4j than all the other contributors, including yourself, combined. Flaunting the log4j brand in my face is shameless. Since you arrived and filibustered the log4j project, it has gone nowhere. We used make log4j releases regularly. Now we are lucky if there is one release a year. We used to have a new committer once a semester. Log4j project was joined only by one new committer in the last 4 years, namely Ralh. All log4j comitters, excluding Ralph, but including you, have been nominated by me. Accusing me of wanting to get political advantage at the expense of Apache and the log4j brand, is shameless. If the current majority of log4j committers wish to continue the status quo, than that's that. However, I propose a path whereby log4j would converge on SLF4J, an established and popular API. This will make life easier for thousands of java developers. I wish more of them could speak up. If you really think that "java.util.logging has already won the API standardization war years ago" (quoting your own words) then none of this matters to you. By the way, how can you say such thing as logging PMC chair, especially since only a small minority of Java projects use j.u.l.? We used to have elections for PMC chair every year. There has not been any since you were elected in 2005. Why is that? Why hasn't log4j evolved in the last 4 years? Is it because you don't want it to evolve? -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Geir W. wrote:
The changes needs to be done on every logging statement using an object,
*)log.debug(object)->log.debug(object.toString())*)log.fatal("")
needs to be modified to log.error("");
*)NDC statements must be migrated to MDC
*)...
Modifying log.debug(object) to log.debug(object.toString()) can be done very
quickly, for two reasons. Usually, there are very few such statements. Just as
importantly, they are detected and shown by the compiler.
>>Ceki Gulcu writes:
>>"even very large projects can be migrated to the SLF4J API within
half an hour"
from sl4j.org:
"Suppose that your CRM application uses log4j for its logging. However,
one of your important clients request that logging be performed through
JDK 1.4 logging. If your application is riddled with thousands of direct
log4j calls, migration to JDK 1.4 would be a long and error-prone process."
So why is it that moving from log4j -> to jdk 1.4 would be a long and
error-prone process
but going from log4j -> sl4j is smoother than a baby's bottom?
The statement in slf4j.org is not accurate. In the case of source code migration
for the CRM, you would have to maintain two code bases, one for log4j and one
for jul, that is bound to be difficult. As for the migration itself, there are
no public tools for such migration. There is one for log4j to slf4j migration.
But please, maintain 100% compatibility in log4j!
There is actually a way to maintain 100% source code compatibility. The
org.apache.log4j.Logger/Category classes would cetain their existing method
signatures but would delegate to org.apache.log4j.impl.Logger class which would
implement the org.slf4j.Logger interface. This is feasible as demonstrated by
the log4j-over-slf4j module in SLF4J.
Clients wishing to use the existing log4j classes could continue to do so. Those
wishing to standardize on the SLF4J API could do so as well. Direct use of
org.apache.log4j.impl.Logger would technically be possible but discouraged.
As described above, there is a way to converge on the SLF4J API without breaking
compatibility.
--
Ceki Gülcü
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
The discussion between Curt Arnold, Jacob Kjome and Ceki Gulcu tells me
there is more to this than meets the eye, especially when it comes to
the political side of it.
Going back to the technical side, and the original proposal:
>>Ceki Gulcu writes:
>>"Unfortunately, the adoption of the SLF4J API by log4j will be break
100% compatibility with existing log4j >>clients."
The motivation for breaking 100% compatibility should be rather strong,
given the widespread use of log4j.
Having to go through the whole codebase and doing manual modifications,
or even worse, automatic migration changes, is a risk, and time
consuming. Maybe not so much on the code change itself, but on
regression testing!
The changes needs to be done on every logging statement using an object,
*)log.debug(object)->log.debug(object.toString())
*)log.fatal("") needs to be modified to log.error("");
*)NDC statements must be migrated to MDC
*)...
>>Ceki Gulcu writes:
>>"even very large projects can be migrated to the SLF4J API within
half an hour"
from sl4j.org:
"Suppose that your CRM application uses log4j for its logging. However,
one of your important clients request that logging be performed through
JDK 1.4 logging. If your application is riddled with thousands of direct
log4j calls, migration to JDK 1.4 would be a long and error-prone process."
So why is it that moving from log4j -> to jdk 1.4 would be a long and
error-prone process
but going from log4j -> sl4j is smoother than a baby's bottom?
I might go for sl4j in next project, and then using the log4j-over-sl4j
bridge.
Thus the log4j-development can be spent on improving the
appenders/configurators and backend part, instead of spending time on
sl4j-migration.
But please, maintain 100% compatibility in log4j!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Hi Ceki, On 12/4/2008 2:33 PM, Ceki Gulcu wrote: > The point here is not comparing implementations but to have API > convergence. It is less a technical matter (there not an ounce of > doubt that it can be done with good results) than a question of > collective will of log4j committers and log4j users. > But what exactly is the advantage of implementing the SLF4J API rather than simply placing slf4j-log4j.jar in the classpath? The primary one I can see is that Log4j repository selectors will work even when using the SLF4J API. But I think we're already in agreement that they aren't the panacea to logging separation we thought they were a few years back. So, that's hardly a relevant argument for the move. Why introduce change to fix something that isn't broken? The only psuedo-tangible argument you make is that implementing the SLF4J API directly will provide "API convergence". But that's what SLF4J already provides today, no? I think many of us rightly balked at implementing the UGLI API, which resulted in the timultuous experiment called nLog4j. You now admit that our argument was "reasonable" back then, even though you clearly felt it was unreasonable at the time as evidenced by the fact that you forked Log4j and mostly ceased contributing to the original project you founded. You now imply, once again, that those opposed to your proposal are unreasonable. Hmmm I've not yet made up my mind on the issue, but contrary to your certainty that what you propose can do nothing but good, there are several reasons not to do it... 1. The existing soluton of simply placing slf4j-log4j.jar in the classpath works just fine. You can't argue that it's just too many jars. First, they're of SLF4J's own creation (granted, by necessity). Second, most apps already need 10's of jars to run. What's one more? 2. Apache licensing and process issues 3. Time and effort in performing the work, maintaining it, and supporting it... or just even considering it for that matter. I've already taken time away from doing other things to respond to this proposal. That's not to say you shouldn't have made the proposal, but the commitment of peoples time to consider it can't be overlooked. 4. The introduction of any new code brings with it the risk of breakage of the existing code. I'm sure others can think of more. Again, this is not to say it shouldn't be done, but it's clearly not the slam-dunk you claim. > Curt has plainly expressed his feelings. What do others think? Curt has been an excellent steward of Log4j for a number of years now and I'm disappointed to see his opinions discounted out of hand. He's always taken a conservative approach to changes in Log4j. For the most part, I think that approach has served the Log4j community well. Why does it need to be "released within days"? Why not give Curt time to try things out? Any testing will bear out your assertion that it's "less a technical matter". If you wish to gain support of the "collective will of the Log4j committers and Log4j users", then let those willing kick the tires report results and give everyone the time and evidence they need to make an informed decision. Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Curt Arnold wrote: On Dec 4, 2008, at 6:26 AM, Ceki Gulcu wrote: Hello Ralph, Thank for you for your reply. Logback as the basis for log4j 2.0 is a larger step than what I had in mind. Implementation of the SLF4J API directly in log4j is a low-hanging fruit but having a significant positive impact on the java community, by virtue of de facto standardization. IMHO, breaking 100% compatibility would be a reasonable price to pay given the benefits involved, namely convergence into a logging standard. As far as I can tell, there is no significant practical advantage to our user community to do a direct implementation of SLF4J in log4j over the facade implementation provided by slf4j.org. I have never seen a significant performance difference between the two approaches and a direct implementation has several strong negatives to the log4j community and users that have been previously discussed. A direct implementation of log4j would be beneficial to users calling the SLF4J API with log4j as the underlying implementation. Nothing earth shaking but still moderately beneficial. Although adoption of SLF4J will break clients passing objects as the message parameter, such usage is very limited. So clients wishing to migrate to the new API can do so very quickly. Binary compatibility for clients invoking org.apache.log4j.Logger can be maintained by implementing the SLF4J in a different package. Thus, clients could replace log4j 1.2.x jar with log4j 1.4.jar without being affected. New code can refer to SLF4J API and legacy code can continue to refer to org.apache.log4j. However, I could see a significant political advantage to SLF4J to have an implicit endorsement from the ASF and in my mind that is what this proposal is about. In my mind, java.util.logging has already won the API standardization war years ago, but it has been mostly limited the available appenders and configurators. One of the design goals (https://issues.apache.org/jira/browse/LOG4J2-5) for log4j 2.0 is to have the back-end classes independent of the API, so that the bulk of log4j 2 is isolated from the client's API choice. Look Curt, SLF4J does not need ASF's endorsement. The project is doing well as it is. By the way, I resent the implication. Moreover, if you believe that java.util.logging has already won the API standardization war years ago, what are you doing working on log4j? I believe that we would render the java community a valuable service by converging on a popular and well-established logging API. In 2004 one could have reasonably argued that the SLF4J API was not stable or unsuitable, that is no longer the case today. Curt, I don't expect you to jump up and down with joy about my proposal. However, I hope you can see the bigger picture, especially since we can preserve compatibility for existing clients. With the breaking API change, it should not be called Apache log4j 1.4 and should not use the org.apache.log4j package names for the modified classes. Back when SLF4J spun out from the ASF, SLF4J.org or QoS.ch provided a log4j variant called nlog4j which is no longer available. If this has to come to pass, I'd much rather see an Apache nlog4j or slog4j than confuse the Apache log4j brand. The motivation here is to converge, not to create yet another implementation. The Apache process makes it difficult enough get non-controversial maintenance releases out in days, let alone something with as much potential for disruption as this. If we can reach a decision, it can be done in days. The hard part is reaching a decision. I haven't been able to contribute much code since Hurricane Ike, but I just returned from a long Thanksgiving trip and was expecting to work on getting a log4j 1.2.16 release candidate ready. However, I'll explore setting up an experimental take on a direct implementation of SLF4J without doing violence to Java compatibility expectations, so that a side-by-side comparison of a direct and facade implementation could be made. The point here is not comparing implementations but to have API convergence. It is less a technical matter (there not an ounce of doubt that it can be done with good results) than a question of collective will of log4j committers and log4j users. Curt has plainly expressed his feelings. What do others think? -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 4, 2008, at 6:26 AM, Ceki Gulcu wrote: Hello Ralph, Thank for you for your reply. Logback as the basis for log4j 2.0 is a larger step than what I had in mind. Implementation of the SLF4J API directly in log4j is a low-hanging fruit but having a significant positive impact on the java community, by virtue of de facto standardization. IMHO, breaking 100% compatibility would be a reasonable price to pay given the benefits involved, namely convergence into a logging standard. As far as I can tell, there is no significant practical advantage to our user community to do a direct implementation of SLF4J in log4j over the facade implementation provided by slf4j.org. I have never seen a significant performance difference between the two approaches and a direct implementation has several strong negatives to the log4j community and users that have been previously discussed. However, I could see a significant political advantage to SLF4J to have an implicit endorsement from the ASF and in my mind that is what this proposal is about. In my mind, java.util.logging has already won the API standardization war years ago, but it has been mostly limited the available appenders and configurators. One of the design goals (https://issues.apache.org/jira/browse/LOG4J2-5 ) for log4j 2.0 is to have the back-end classes independent of the API, so that the bulk of log4j 2 is isolated from the client's API choice. SLF4J is a very stable API which has not changed incompatibly since version 1.0-beta5, released on August 2005. Client code compiled against SLF4J 1.0-beta5 will compile against any subsequent version. Client code compiled against SLF4J 1.0-beta5 will run with any subsequent version (runtime/binary compatibility). If we can reach an agreement, SLF4J-compliant log4j can be released within *days*. It can be named log4j 1.4 or log4j 2.0. If it were named 1.4, that version could form the base for log4j 2.0. I will respond to Scott's message separately. With the breaking API change, it should not be called Apache log4j 1.4 and should not use the org.apache.log4j package names for the modified classes. Back when SLF4J spun out from the ASF, SLF4J.org or QoS.ch provided a log4j variant called nlog4j which is no longer available. If this has to come to pass, I'd much rather see an Apache nlog4j or slog4j than confuse the Apache log4j brand. The Apache process makes it difficult enough get non-controversial maintenance releases out in days, let alone something with as much potential for disruption as this. I haven't been able to contribute much code since Hurricane Ike, but I just returned from a long Thanksgiving trip and was expecting to work on getting a log4j 1.2.16 release candidate ready. However, I'll explore setting up an experimental take on a direct implementation of SLF4J without doing violence to Java compatibility expectations, so that a side-by-side comparison of a direct and facade implementation could be made. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Hello Scott,
There are several reasons. First, Strings are immutable while objects
are not. Second, since everything is an object in Java, when there are
several variants of a printing method with the same name (overloaded
methods), having object as the first parameter creates too much
ambiguity in method name resolution. There is much less ambiguity in
method resolution when the message is of type java.lang.String.
Admittedly, this is less flexible than allowing java.lang.Object as
the message type. One degree of liberty is lost. There are many ways
in which a java.lang.Object can be transformed into java.lang.String
whereas there is much less liberty when transforming java.lang.String
into java.lang.String.
As Thorbjørn mentioned, in SLF4J it is still possible to pass
additional arguments of type java.lang.Object. Only the message must be
of type java.lang.String. An SLF4J implementation is free to preserve
these additional parameters as java.lang.Object.
If logger implements org.slf4j.Logger, then one can write
String name = "Scott";
logger.debug("Hello Scott");
logger.debug("Hello {}", name);
Both log statements will print as "Hello Scott". However, the latter
log statement will contain 'name' as a parameter. The SLF4J
implementation can choose to preserve or to discard this parameter in
the LoggingEvent.
SLF4J allows for 0,1,2 or an array of parameters. Thus, you can write
Map aMap = ...;
List aList = ...;
logger.debug("Hello", new Object[]{new Integer(37), aMap, aList});
The output message will be "Hello" but assuming the argument array is
preserved in the logging event, the logger implementation can process
the parameter array as it sees fit. In other words, adoption of the
SLF4J will not hinder support for properties. On the very contrary, it
*enables* such processing.
Scott Deboy wrote:
I'd like to understand why the Logger trace/debug etc. base methods take a string instead of an object.
I'd like to think there's usefulness in supporting something like
ObjectRenderer or ReflectionPolicy/MapPolicy+RewriteAppender - supporting only
strings makes this difficult.
Whatever we do moving forward, I'd like to see increased support for
properties. MDC and NDC are useful, but something that isn't thread specific
would be useful (one reason why property rewrite policy/rewriteappender were
created was to get around this limitation).
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax:503.222.0185
[EMAIL PROTECTED]
www.comotivsystems.com
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Hello Ralph, Thank for you for your reply. Logback as the basis for log4j 2.0 is a larger step than what I had in mind. Implementation of the SLF4J API directly in log4j is a low-hanging fruit but having a significant positive impact on the java community, by virtue of de facto standardization. IMHO, breaking 100% compatibility would be a reasonable price to pay given the benefits involved, namely convergence into a logging standard. SLF4J is a very stable API which has not changed incompatibly since version 1.0-beta5, released on August 2005. Client code compiled against SLF4J 1.0-beta5 will compile against any subsequent version. Client code compiled against SLF4J 1.0-beta5 will run with any subsequent version (runtime/binary compatibility). If we can reach an agreement, SLF4J-compliant log4j can be released within *days*. It can be named log4j 1.4 or log4j 2.0. If it were named 1.4, that version could form the base for log4j 2.0. I will respond to Scott's message separately. Ralph Goers wrote: I would support this in 2.0. Work has yet to start on that though. I =20 don't see how 100% compatibility can be maintained anyway as the plan, =20= as I understand it, includes moving to a later minimum Java release =20 and removing deprecated classes. The questions I wonder about are: 1. It would be easier if the author of Logback :-) was willing to =20 donate it to Apache as the basis for Log4j 2.0. 2. Would the community be willing to accept it since it has major =20 differences with Log4j. Ralph -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
Scott Deboy skrev den 04-12-2008 05:22:
I'd like to understand why the Logger trace/debug etc. base methods take a string instead of an object.
I'd like to think there's usefulness in supporting something like
ObjectRenderer or ReflectionPolicy/MapPolicy+RewriteAppender - supporting only
strings makes this difficult.
Whatever we do moving forward, I'd like to see increased support for
properties. MDC and NDC are useful, but something that isn't thread specific
would be useful (one reason why property rewrite policy/rewriteappender were
created was to get around this limitation).
If I understand Ceki correctly it is the MESSAGE that is a String, not
the additional arguments for the formatting part.
The message can contain {}-pairs which is then replaced with additional
arguments - these can be objects. This allows for postponding the
flattening process til after it has been decided that the event will not
be discarded.
On a related note I would like to have better terms than "NDC" and "MDC"
as nobody can figure out what they do unless they do a lot of reading.
Additionally the two terms are so similar I tend to confuse the two.
MDC could be "Log ThreadMap"?
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
On Dec 3, 2008, at 5:41 AM, Ceki Gulcu wrote: Hello, As you are probably aware, more and more projects are adopting the SLF4J API. I would venture say that SLF4J's adoption rate is roughly equivalent to that of log4j itself. Although the SLF4J API is not perfect, most SLF4J users seem to be extremely happy with it. Harry Metske synthesized various logging paths in JSPWiki https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp I was taken aback by the picture he paints. I think we as log4j committers owe it to Java developers to propose a saner logging model. Given the multiplicity of logging APIs in the Java world, I propose that log4j implement the SLF4J API directly. This can be done in the next version of log4j, say 1.3 or 2.0. Unfortunately, the adoption of the SLF4J API by log4j will be break 100% compatibility with existing log4j clients. More precisely, logging statements passing java.lang.Object as the message parameter will need to be changed to java.lang.String. Assuming that the proportion of logging statements using objects instead string is extremely small, comparatively few users will be affected. More importantly, in my experience, even very large projects can be migrated to the SLF4J API within half an hour. There is even a tool called slf4j-migrator to help with such migration [1]. Is there support for my proposal? [1] http://www.slf4j.org/migrator.html -- Ceki Gülcü I've logged this issue as https://issues.apache.org/jira/browse/LOG4J2-27 and Scott's desire for increased support for properties as https://issues.apache.org/jira/browse/LOG4J2-28 . I've attached a PDF version of the referenced OpenOffice file to LOG4J2-27. If the proposal is that direct support for SLF4J be considered as a potential feature of log4j 2.0 as previously described on this list (a designed for Java 5 replacement for log4j 1.x with fine grained concurrency), then LOG4J2-27 captures that potential feature for consideration at the proper time. If the proposal is to create a branch of the log4j 1.2 code base that directly implements SLF4J, that is a different matter. I could recount all sorts of previous discussions on the issues involved, but I don't want to do that if that is not the proposal. On Dec 3, 2008, at 7:18 PM, Ralph Goers wrote: I would support this in 2.0. Work has yet to start on that though. I =20 don't see how 100% compatibility can be maintained anyway as the plan, =20= as I understand it, includes moving to a later minimum Java release =20 and removing deprecated classes. The questions I wonder about are: 1. It would be easier if the author of Logback :-) was willing to =20 donate it to Apache as the basis for Log4j 2.0. 2. Would the community be willing to accept it since it has major =20 differences with Log4j. Ralph logback would have to go through the Incubator PMC like any externally developed code base. Given the history and the license differences, I have intentionally not examined logback and can make no statement as its desirability as a basis for a designed for Java 5 log4j. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Implementing the SLF4J API directly
I'd like to understand why the Logger trace/debug etc. base methods take a string instead of an object. I'd like to think there's usefulness in supporting something like ObjectRenderer or ReflectionPolicy/MapPolicy+RewriteAppender - supporting only strings makes this difficult. Whatever we do moving forward, I'd like to see increased support for properties. MDC and NDC are useful, but something that isn't thread specific would be useful (one reason why property rewrite policy/rewriteappender were created was to get around this limitation). Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax:503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Wed 12/3/2008 5:18 PM To: Log4J Developers List Subject: Re: [PROPOSAL] Implementing the SLF4J API directly I would support this in 2.0. Work has yet to start on that though. I =20 don't see how 100% compatibility can be maintained anyway as the plan, =20= as I understand it, includes moving to a later minimum Java release =20 and removing deprecated classes. The questions I wonder about are: 1. It would be easier if the author of Logback :-) was willing to =20 donate it to Apache as the basis for Log4j 2.0. 2. Would the community be willing to accept it since it has major =20 differences with Log4j. Ralph On Dec 3, 2008, at 3:41 AM, Ceki Gulcu wrote: > Hello, > > As you are probably aware, more and more projects are adopting the > SLF4J API. I would venture say that SLF4J's adoption rate is roughly > equivalent to that of log4j itself. Although the SLF4J API is not > perfect, most SLF4J users seem to be extremely happy with it. > > Harry Metske synthesized various logging paths in JSPWiki > > https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp > > I was taken aback by the picture he paints. I think we as log4j > committers owe it to Java developers to propose a saner logging model. > > Given the multiplicity of logging APIs in the Java world, I propose > that log4j implement the SLF4J API directly. This can be done in the > next version of log4j, say 1.3 or 2.0. > > Unfortunately, the adoption of the SLF4J API by log4j will be break > 100% compatibility with existing log4j clients. More precisely, > logging statements passing java.lang.Object as the message parameter > will need to be changed to java.lang.String. Assuming that the > proportion of logging statements using objects instead string is > extremely small, comparatively few users will be affected. More > importantly, in my experience, even very large projects can be > migrated to the SLF4J API within half an hour. > > There is even a tool called slf4j-migrator to help with such > migration [1]. > > Is there support for my proposal? > > [1] http://www.slf4j.org/migrator.html > > -- > Ceki Gülcü > > - > 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] <>- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Implementing the SLF4J API directly
I would support this in 2.0. Work has yet to start on that though. I =20 don't see how 100% compatibility can be maintained anyway as the plan, =20= as I understand it, includes moving to a later minimum Java release =20 and removing deprecated classes. The questions I wonder about are: 1. It would be easier if the author of Logback :-) was willing to =20 donate it to Apache as the basis for Log4j 2.0. 2. Would the community be willing to accept it since it has major =20 differences with Log4j. Ralph On Dec 3, 2008, at 3:41 AM, Ceki Gulcu wrote: Hello, As you are probably aware, more and more projects are adopting the SLF4J API. I would venture say that SLF4J's adoption rate is roughly equivalent to that of log4j itself. Although the SLF4J API is not perfect, most SLF4J users seem to be extremely happy with it. Harry Metske synthesized various logging paths in JSPWiki https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp I was taken aback by the picture he paints. I think we as log4j committers owe it to Java developers to propose a saner logging model. Given the multiplicity of logging APIs in the Java world, I propose that log4j implement the SLF4J API directly. This can be done in the next version of log4j, say 1.3 or 2.0. Unfortunately, the adoption of the SLF4J API by log4j will be break 100% compatibility with existing log4j clients. More precisely, logging statements passing java.lang.Object as the message parameter will need to be changed to java.lang.String. Assuming that the proportion of logging statements using objects instead string is extremely small, comparatively few users will be affected. More importantly, in my experience, even very large projects can be migrated to the SLF4J API within half an hour. There is even a tool called slf4j-migrator to help with such migration [1]. Is there support for my proposal? [1] http://www.slf4j.org/migrator.html -- Ceki Gülcü - 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]
[PROPOSAL] Implementing the SLF4J API directly
Hello, As you are probably aware, more and more projects are adopting the SLF4J API. I would venture say that SLF4J's adoption rate is roughly equivalent to that of log4j itself. Although the SLF4J API is not perfect, most SLF4J users seem to be extremely happy with it. Harry Metske synthesized various logging paths in JSPWiki https://issues.apache.org/jira/secure/attachment/12394188/jspwiki-log.odp I was taken aback by the picture he paints. I think we as log4j committers owe it to Java developers to propose a saner logging model. Given the multiplicity of logging APIs in the Java world, I propose that log4j implement the SLF4J API directly. This can be done in the next version of log4j, say 1.3 or 2.0. Unfortunately, the adoption of the SLF4J API by log4j will be break 100% compatibility with existing log4j clients. More precisely, logging statements passing java.lang.Object as the message parameter will need to be changed to java.lang.String. Assuming that the proportion of logging statements using objects instead string is extremely small, comparatively few users will be affected. More importantly, in my experience, even very large projects can be migrated to the SLF4J API within half an hour. There is even a tool called slf4j-migrator to help with such migration [1]. Is there support for my proposal? [1] http://www.slf4j.org/migrator.html -- Ceki Gülcü - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
