logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: [PROPOSAL] Implementing the SLF4J API directly
Date Thu, 04 Dec 2008 06:34:53 GMT

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


Mime
View raw message