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 <[email protected]>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 > > >
