You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gulcu <ce...@qos.ch> on 2008/12/03 12:41:00 UTC
[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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Curt Arnold <ca...@apache.org>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Paul Smith <ps...@aconex.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by saimen54 <sa...@hotmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Jacob Kjome <ho...@visi.com>.
On Mon, 08 Dec 2008 10:06:44 +0100
Thorbjørn Ravn Andersen <th...@gmail.com> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Jacob Kjome <ho...@visi.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ralph Goers <ra...@dslextreme.com>.
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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by "Geir W." <ge...@gmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Jacob Kjome <ho...@visi.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Curt Arnold <ca...@apache.org>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Curt Arnold <ca...@apache.org>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ralph Goers <ra...@dslextreme.com>.
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
Posted by Scott Deboy <sd...@comotivsystems.com>.
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
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Ralph Goers [mailto:ralph.goers@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
> sdeboy@comotivsystems.com
> www.comotivsystems.com
>
>
> -----Original Message-----
> From: Ralph Goers [mailto:ralph.goers@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ralph Goers <ra...@dslextreme.com>.
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
> sdeboy@comotivsystems.com
> www.comotivsystems.com
>
>
> -----Original Message-----
> From: Ralph Goers [mailto:ralph.goers@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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [PROPOSAL] Implementing the SLF4J API directly
Posted by Scott Deboy <sd...@comotivsystems.com>.
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
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Ralph Goers [mailto:ralph.goers@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ralph Goers <ra...@dslextreme.com>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [PROPOSAL] Implementing the SLF4J API directly
Posted by Scott Deboy <sd...@comotivsystems.com>.
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:ceki@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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Curt Arnold <ca...@apache.org>.
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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 = 100000;
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 best suits their needs. The SLF4J approach enforces a
> choice of a particular formatter over any other formatter.
The SLF4J formatter indeed exposes one formatter in a convenient
way. However, it does not preclude extending SLF4J in the way LogMF
extends log4j. Not only such extensions are possible, they already
exist [1]. However, SLF4J caters for the most common case in a
convenient way. I don't have a marketing survey to prove this, but if
you use the SLF4J API, even for a short while, you'll see what I mean.
> 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.
Let me remind you that UGLI (the predecessor of SLF4J) was 100%
compatible with log4j. The String incompatibly issue arose later,
after it became clear that log4j was not interested in UGLI (because
it was not yet proven). But I am digressing.
With respect to an exploratory project, I can set it up under
https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_LOG4JS
> In my earlier discussion about the ASF and log4j brand, my intention
> was not denigrate your role in founding the project or try to claim
> responsibility for your work. It is just that a users expectation
> from the Apache and log4j brand is that Apache does not break
> compatibility on dot releases and log4j 1.x+1 is compatible with log4j
> 1.x. There is no expectation that logback, nlog4j, slog4j, log4j 2 or
> any other designation is binary and source compatible with log4j
> 1.x. There is an expectation that log4j 2 will address locking issues
> and use Java 5 idioms. If there is a log4j variant that supports
> SLF4J but is not compatible with log4j 1.x, I'd strongly prefer using
> a different name but synchronizing the version numbers so that slog4j
> 1.2.18 would be a variant of log4j 1.2.18 that was mostly log4j
> compatible but supported SLF4J.
I think it is fair to say that Apache, as a foundation, does not care
about log4j version designations. Log4j committers can decide about
the future of log4j without deferring to the board or worrying about
the Apache brand. As long as we can get our shit together here, the
foundation is likely to be supportive of whatever we decide, including
backward incompatible changes. Of course, that does not mean we
should, it means we can. But I am digressing.
As log4j committers, our job is to respond to user demand. Log4j
committers would do the larger java developer community a valuable
service by helping in java logging disambiguation. I don't think
log4js is the answer. Java logging does not need more choice. It needs
consolidation.
The current java logging mess is not good for anyone, including
log4j. As such, I consider log4js as only a start. In the long run,
log4js and log4j should be merged.
> However, all that is labeling issues for code that we have not seen or
> written.
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
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Curt Arnold <ca...@apache.org>.
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 not denigrate your role in founding the project or try to claim
responsibility for your work. It is just that a users expectation
from the Apache and log4j brand is that Apache does not break
compatibility on dot releases and log4j 1.x+1 is compatible with log4j
1.x. There is no expectation that logback, nlog4j, slog4j, log4j 2 or
any other designation is binary and source compatible with log4j 1.x.
There is an expectation that log4j 2 will address locking issues and
use Java 5 idioms. If there is a log4j variant that supports SLF4J
but is not compatible with log4j 1.x, I'd strongly prefer using a
different name but synchronizing the version numbers so that slog4j
1.2.18 would be a variant of log4j 1.2.18 that was mostly log4j
compatible but supported SLF4J. However, all that is labeling issues
for code that we have not seen or written.
You still have commit rights on the ASF SVN. I would strongly object
to you modifying the trunk to experiment since we are very near to a
log4j maintenance release. However, you float a proposal to copy the
trunk into the sandbox and apply your desired modifications and let
the list evaluate your proposal as expressed in concrete code, I'd
vote +1 to allow you to experiment.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Curt Arnold <ca...@apache.org>.
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 = 100000;
>
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ceki Gulcu <ce...@qos.ch>.
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 = 100000;
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Curt Arnold <ca...@apache.org>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Thorbjørn Ravn Andersen <th...@gmail.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Paul Smith <ps...@aconex.com>.
>
> 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
Posted by Ceki Gulcu <ce...@qos.ch>.
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
>
> sdeboy@comotivsystems.com
>
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [PROPOSAL] Implementing the SLF4J API directly
Posted by Scott Deboy <sd...@comotivsystems.com>.
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
sdeboy@comotivsystems.com
www.comotivsystems.com
-----Original Message-----
From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [PROPOSAL] Implementing the SLF4J API directly
Posted by Ralph Goers <ra...@dslextreme.com>.
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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org