incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Janne Jalkanen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JSPWIKI-376) Move from log4j to slf4j
Date Tue, 02 Dec 2008 19:02:44 GMT

    [ https://issues.apache.org/jira/browse/JSPWIKI-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652457#action_12652457
] 

Janne Jalkanen commented on JSPWIKI-376:
----------------------------------------

Oops, but we can add the "implements Serializable".  Looks like a simple oversight ;-)

I don't think performance is a bottleneck, and as you point out in the encoded documentation,
evaluating the log level is < 1% of the actual cost of logging (some other email from you
says it's 25ns for log4j and 10ns for logback).  So by wrapping the code in isDebugEnabled()
prior to invoking String.format(), I think we're fine.

The Java String.format() is standard, and therefore familiar to developers.  It also means
that we're not tied to slf4j in the future, in case need arises to replace it with something
else.

The slf4j manual or faq do not mention anything about avoiding wrappers...  Is it not logback's
fault then?  (Frankly, I still don't understand what the problem is unless you're looking
at the call stack somehow, but I couldn't find anything relating to it in the code).

I would expect that in the future we would add localized logging through the use of implementing
something like Logger.localizedInfo( String messagekey, Object... args );


> Move from log4j to slf4j
> ------------------------
>
>                 Key: JSPWIKI-376
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-376
>             Project: JSPWiki
>          Issue Type: Improvement
>          Components: Core & storage
>            Reporter: Janne Jalkanen
>            Assignee: Harry Metske
>            Priority: Minor
>             Fix For: 3.0
>
>         Attachments: jspwiki-log.odp
>
>
> SLF4J allows far more flexible logging than log4j, and it would allow us to get rid of
these dumb log4j compatibility problems that sometimes occur.  It also plays better with other
applications, gives the user more power to choose how to log his stuff, and is also pretty
cool otherwise. The change would be relatively trivial, and would probably be largely invisible
to the users (since we could continue shipping with necessary log4j jars).
> http://www.slf4j.org
> The license is MIT/X11, so that's fine.
> Opinions?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message