You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <le...@hazlewood.com> on 2009/03/25 15:44:22 UTC
SLF4J
Now that Maven is in place and things feel like they're on rails, I'd like
to revisit the SLF4J issue.
Can we remove commons-logging in favor of SLF4J now?
Don't worry, I'm not proposing our own wrapper on top of it ;) We could
just use the slf4j API directly in code and move on. Is that ok with
everyone?
- Les
Re: SLF4J
Posted by Kalle Korhonen <ka...@gmail.com>.
Agree it's the right move; using slf4j is fairly transparent so I'd be
surprised if anybody had an issue with it.
Kalle
On Wed, Mar 25, 2009 at 7:44 AM, Les Hazlewood <le...@hazlewood.com> wrote:
> Now that Maven is in place and things feel like they're on rails, I'd like
> to revisit the SLF4J issue.
>
> Can we remove commons-logging in favor of SLF4J now?
>
> Don't worry, I'm not proposing our own wrapper on top of it ;) We could
> just use the slf4j API directly in code and move on. Is that ok with
> everyone?
>
> - Les
>
Re: SLF4J
Posted by Jeremy Haile <jh...@fastmail.fm>.
Sweet - I did not realize that. Let's just go with SLF4J!
On Mar 25, 2009, at 1:17 PM, Kalle Korhonen wrote:
> The time it takes to create objects in Java is negligible compared
> to string
> concatenation. I'd strongly advice against creating custom logging
> wrappers,
> they are rarely used consistently. Slf4j supports logging messages
> with
> format and array of objects as parameters,
> http://www.slf4j.org/apidocs/org/slf4j/Logger.html.
>
> Kalle
>
>
> On Wed, Mar 25, 2009 at 10:09 AM, Jeremy Haile <jh...@fastmail.fm>
> wrote:
>
>> Without arguing either side, just be aware that with varargs, some
>> of the
>>> additional overhead is there even if debug is not enabled. That
>>> is, the
>>> compiler turns the above into:
>>>
>>> log.debug( "User with ID {0} logged into realm {1}", new Object[
>>>> ]{userId, realm});
>>>>
>>>
>>> which creates a new Object[ ] (that is garbage collected
>>> immediately), so
>>> it's still not "free", even if it is less expensive than String
>>> concatenation.
>>>
>>> Craig
>>>
>>
>> Thanks Craig - hadn't thought about that. Even if there is still a
>> small
>> performance penalty (the Object[] creation), it does significantly
>> clean up
>> the code. I'm not strongly opinionated for or against it. But I'd
>> be more
>> open to a custom logging wrapper that offers some value-adds like
>> this vs.
>> one that is simply just another wrapper layer.
>>
Re: SLF4J
Posted by Kalle Korhonen <ka...@gmail.com>.
The time it takes to create objects in Java is negligible compared to string
concatenation. I'd strongly advice against creating custom logging wrappers,
they are rarely used consistently. Slf4j supports logging messages with
format and array of objects as parameters,
http://www.slf4j.org/apidocs/org/slf4j/Logger.html.
Kalle
On Wed, Mar 25, 2009 at 10:09 AM, Jeremy Haile <jh...@fastmail.fm> wrote:
> Without arguing either side, just be aware that with varargs, some of the
>> additional overhead is there even if debug is not enabled. That is, the
>> compiler turns the above into:
>>
>> log.debug( "User with ID {0} logged into realm {1}", new Object[
>>> ]{userId, realm});
>>>
>>
>> which creates a new Object[ ] (that is garbage collected immediately), so
>> it's still not "free", even if it is less expensive than String
>> concatenation.
>>
>> Craig
>>
>
> Thanks Craig - hadn't thought about that. Even if there is still a small
> performance penalty (the Object[] creation), it does significantly clean up
> the code. I'm not strongly opinionated for or against it. But I'd be more
> open to a custom logging wrapper that offers some value-adds like this vs.
> one that is simply just another wrapper layer.
>
Re: SLF4J
Posted by Jeremy Haile <jh...@fastmail.fm>.
> Without arguing either side, just be aware that with varargs, some
> of the additional overhead is there even if debug is not enabled.
> That is, the compiler turns the above into:
>
>> log.debug( "User with ID {0} logged into realm {1}", new Object[ ]
>> {userId, realm});
>
> which creates a new Object[ ] (that is garbage collected
> immediately), so it's still not "free", even if it is less expensive
> than String concatenation.
>
> Craig
Thanks Craig - hadn't thought about that. Even if there is still a
small performance penalty (the Object[] creation), it does
significantly clean up the code. I'm not strongly opinionated for or
against it. But I'd be more open to a custom logging wrapper that
offers some value-adds like this vs. one that is simply just another
wrapper layer.
Re: SLF4J
Posted by Craig Russell <Cr...@Sun.COM>.
On 25.03.2009, at 09:55, Jeremy Haile wrote:
> I argued against writing our own wrappers in the past, but we have
> created some wrappers on another project that I feel are
> beneficial. Since we're discussing going through the code and
> replacing all of our log calls, I thought I'd mention it here.
>
> Our wrapper takes in var-args and internally uses the MessageFormat
> class to substitute in arguments. This removes the problem when
> logging of string concatenation being slow since the string
> concatenation only takes place if the log level is set.
>
> So code that used to look like this:
> if( log.isDebugEnabled() ) {
> log.debug( "User with ID [" + userId + "] logged into realm [" +
> realm + "]" );
> }
>
> can now look like:
> log.debug( "User with ID {0} logged into realm {1}", userId, realm);
Without arguing either side, just be aware that with varargs, some of
the additional overhead is there even if debug is not enabled. That
is, the compiler turns the above into:
> log.debug( "User with ID {0} logged into realm {1}", new Object[ ]
> {userId, realm});
which creates a new Object[ ] (that is garbage collected immediately),
so it's still not "free", even if it is less expensive than String
concatenation.
Craig
>
>
> This is cleaner and doesn't incur the cost of string concatenation
> even if the log level is not set to debug. Under the hood it just
> calls SLF4J. If the last argument is an exception, the stacktrace
> gets logged.
>
>
> Thoughts?
>
> Jeremy
>
>
> On Mar 25, 2009, at 10:44 AM, Les Hazlewood wrote:
>
>> Now that Maven is in place and things feel like they're on rails,
>> I'd like
>> to revisit the SLF4J issue.
>>
>> Can we remove commons-logging in favor of SLF4J now?
>>
>> Don't worry, I'm not proposing our own wrapper on top of it ;) We
>> could
>> just use the slf4j API directly in code and move on. Is that ok with
>> everyone?
>>
>> - Les
>
Re: SLF4J
Posted by Les Hazlewood <lh...@apache.org>.
Yeah, I was just about to mention that - you can use up to 3 method
arguments in SLF4J without incurring the new Object[] overhead. I assume
they did that (method overloading) instead of using varargs on purpose for
performance reasons.
Given that we rarely ever log anything with more than 3 arguments, I don't
know that it would be all that useful for this particular project. But I
honestly don't feel strongly either way.
+ 0
Cheers,
Les
On Wed, Mar 25, 2009 at 1:16 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Jeremy Haile wrote:
>
>> I argued against writing our own wrappers in the past, but we have created
>> some wrappers on another project that I feel are beneficial. Since we're
>> discussing going through the code and replacing all of our log calls, I
>> thought I'd mention it here.
>>
>> Our wrapper takes in var-args and internally uses the MessageFormat class
>> to substitute in arguments. This removes the problem when logging of string
>> concatenation being slow since the string concatenation only takes place if
>> the log level is set.
>>
>> So code that used to look like this:
>> if( log.isDebugEnabled() ) {
>> log.debug( "User with ID [" + userId + "] logged into realm [" + realm +
>> "]" );
>> }
>>
>> can now look like:
>> log.debug( "User with ID {0} logged into realm {1}", userId, realm);
>>
> Do you know that you can do the exact same thing with slf4j, except that it
> does not use varargs, but allow you to use up to 3 objects ?
>
> So you have the best of two worlds ...
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: SLF4J
Posted by Emmanuel Lecharny <el...@apache.org>.
Jeremy Haile wrote:
> I argued against writing our own wrappers in the past, but we have
> created some wrappers on another project that I feel are beneficial.
> Since we're discussing going through the code and replacing all of our
> log calls, I thought I'd mention it here.
>
> Our wrapper takes in var-args and internally uses the MessageFormat
> class to substitute in arguments. This removes the problem when
> logging of string concatenation being slow since the string
> concatenation only takes place if the log level is set.
>
> So code that used to look like this:
> if( log.isDebugEnabled() ) {
> log.debug( "User with ID [" + userId + "] logged into realm [" +
> realm + "]" );
> }
>
> can now look like:
> log.debug( "User with ID {0} logged into realm {1}", userId, realm);
Do you know that you can do the exact same thing with slf4j, except that
it does not use varargs, but allow you to use up to 3 objects ?
So you have the best of two worlds ...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: SLF4J
Posted by Jeremy Haile <jh...@fastmail.fm>.
I argued against writing our own wrappers in the past, but we have
created some wrappers on another project that I feel are beneficial.
Since we're discussing going through the code and replacing all of our
log calls, I thought I'd mention it here.
Our wrapper takes in var-args and internally uses the MessageFormat
class to substitute in arguments. This removes the problem when
logging of string concatenation being slow since the string
concatenation only takes place if the log level is set.
So code that used to look like this:
if( log.isDebugEnabled() ) {
log.debug( "User with ID [" + userId + "] logged into realm [" +
realm + "]" );
}
can now look like:
log.debug( "User with ID {0} logged into realm {1}", userId, realm);
This is cleaner and doesn't incur the cost of string concatenation
even if the log level is not set to debug. Under the hood it just
calls SLF4J. If the last argument is an exception, the stacktrace
gets logged.
Thoughts?
Jeremy
On Mar 25, 2009, at 10:44 AM, Les Hazlewood wrote:
> Now that Maven is in place and things feel like they're on rails,
> I'd like
> to revisit the SLF4J issue.
>
> Can we remove commons-logging in favor of SLF4J now?
>
> Don't worry, I'm not proposing our own wrapper on top of it ;) We
> could
> just use the slf4j API directly in code and move on. Is that ok with
> everyone?
>
> - Les
Re: SLF4J
Posted by Les Hazlewood <lh...@apache.org>.
I'm having connectivity issues - I'll have to do commit my changes later
tonight.
On Thu, Mar 26, 2009 at 12:32 PM, Les Hazlewood <lh...@apache.org>wrote:
> I'm committing the resolution for this as I write this. Give it a few min
> (SSL appears to be slow on my end today).
>
>
> On Wed, Mar 25, 2009 at 9:55 PM, Les Hazlewood <lh...@apache.org>wrote:
>
>> Cool, thanks!
>>
>>
>> On Wed, Mar 25, 2009 at 4:22 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
>>
>>> I created an issue for this: https://issues.apache.org/jira/browse/KI-72
>>>
>>>
>>>
>>> On Mar 25, 2009, at 3:19 PM, Niklas Gustavsson wrote:
>>>
>>> On Wed, Mar 25, 2009 at 3:44 PM, Les Hazlewood <le...@hazlewood.com>
>>>> wrote:
>>>>
>>>>> Now that Maven is in place and things feel like they're on rails, I'd
>>>>> like
>>>>> to revisit the SLF4J issue.
>>>>>
>>>>> Can we remove commons-logging in favor of SLF4J now?
>>>>>
>>>>
>>>> Big +1
>>>>
>>>> /niklas
>>>>
>>>
>>>
>>
>
Re: SLF4J
Posted by Les Hazlewood <lh...@apache.org>.
I'm committing the resolution for this as I write this. Give it a few min
(SSL appears to be slow on my end today).
On Wed, Mar 25, 2009 at 9:55 PM, Les Hazlewood <lh...@apache.org>wrote:
> Cool, thanks!
>
>
> On Wed, Mar 25, 2009 at 4:22 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
>
>> I created an issue for this: https://issues.apache.org/jira/browse/KI-72
>>
>>
>>
>> On Mar 25, 2009, at 3:19 PM, Niklas Gustavsson wrote:
>>
>> On Wed, Mar 25, 2009 at 3:44 PM, Les Hazlewood <le...@hazlewood.com>
>>> wrote:
>>>
>>>> Now that Maven is in place and things feel like they're on rails, I'd
>>>> like
>>>> to revisit the SLF4J issue.
>>>>
>>>> Can we remove commons-logging in favor of SLF4J now?
>>>>
>>>
>>> Big +1
>>>
>>> /niklas
>>>
>>
>>
>
Re: SLF4J
Posted by Les Hazlewood <lh...@apache.org>.
Cool, thanks!
On Wed, Mar 25, 2009 at 4:22 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
> I created an issue for this: https://issues.apache.org/jira/browse/KI-72
>
>
>
> On Mar 25, 2009, at 3:19 PM, Niklas Gustavsson wrote:
>
> On Wed, Mar 25, 2009 at 3:44 PM, Les Hazlewood <le...@hazlewood.com> wrote:
>>
>>> Now that Maven is in place and things feel like they're on rails, I'd
>>> like
>>> to revisit the SLF4J issue.
>>>
>>> Can we remove commons-logging in favor of SLF4J now?
>>>
>>
>> Big +1
>>
>> /niklas
>>
>
>
Re: SLF4J
Posted by Jeremy Haile <jh...@fastmail.fm>.
I created an issue for this: https://issues.apache.org/jira/browse/KI-72
On Mar 25, 2009, at 3:19 PM, Niklas Gustavsson wrote:
> On Wed, Mar 25, 2009 at 3:44 PM, Les Hazlewood <le...@hazlewood.com>
> wrote:
>> Now that Maven is in place and things feel like they're on rails,
>> I'd like
>> to revisit the SLF4J issue.
>>
>> Can we remove commons-logging in favor of SLF4J now?
>
> Big +1
>
> /niklas
Re: SLF4J
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Mar 25, 2009 at 3:44 PM, Les Hazlewood <le...@hazlewood.com> wrote:
> Now that Maven is in place and things feel like they're on rails, I'd like
> to revisit the SLF4J issue.
>
> Can we remove commons-logging in favor of SLF4J now?
Big +1
/niklas
Re: SLF4J
Posted by Emmanuel Lecharny <el...@apache.org>.
Les Hazlewood wrote:
> Now that Maven is in place and things feel like they're on rails, I'd like
> to revisit the SLF4J issue.
>
> Can we remove commons-logging in favor of SLF4J now?
>
+1
> Don't worry, I'm not proposing our own wrapper on top of it ;) We could
> just use the slf4j API directly in code and move on. Is that ok with
> everyone?
>
Can't we wrap Slf4j in our own implementation ? Ok, just kidding ... :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: SLF4J
Posted by "Alan D. Cabrera" <al...@gmail.com>.
On Mar 25, 2009, at 7:44 AM, Les Hazlewood wrote:
> Now that Maven is in place and things feel like they're on rails,
> I'd like
> to revisit the SLF4J issue.
>
> Can we remove commons-logging in favor of SLF4J now?
>
> Don't worry, I'm not proposing our own wrapper on top of it ;) We
> could
> just use the slf4j API directly in code and move on. Is that ok with
> everyone?
+1
Regards,
Alan