logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Deboy" <sde...@comotivsystems.com>
Subject RE: [PROPOSAL] Implementing the SLF4J API directly
Date Thu, 04 Dec 2008 04:22:33 GMT
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



Mime
View raw message