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
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
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
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
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
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
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
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
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
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
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
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
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
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
...@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
[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
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
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
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
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)
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
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
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
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
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
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,
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...
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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.
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
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
49 matches
Mail list logo
