Hi Kristian – yes, when adding two strings together, java does that automatically because the new concatenated string is the actual parameter you are passing, so it happens before you enter the log method. By using the varargs calling convention, the concatenation is postponed until after the method is entered. Best regards, Richard Sand | Managing Director PO Box 91824 | Austin | Texas 78709-1824 | USA Office: +1 888 612 8820 ext 02 | Fax: +1 866 304 3754 Mobile: +1 267 984 3651 [image: logo - small] *From:* logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] *On Behalf Of *Kristian Lind *Sent:* Thursday, February 07, 2013 4:36 PM *To:* logback users list *Subject:* Re: [logback-user] commons-logging -> sl4j -> logback And that is of cause no matter if there is sl4j behind the commons-logging I guess ? On Thu, Feb 7, 2013 at 1:11 PM, Brett Walker <brett.walker@geometryit.com> wrote: With log.debug("The object is " + object), it will always call .toString() on object because the string argument needs to be constructed before the call to .debug(). To avoid this use either If (log.isDebugEnabled()) { Log.debug("The object is " + object); } Or the slf/logback usage Log.debug("The object is {0}", object); Which will delay the call to .toString() until it has determined that debug logging is needed. Brett Sent from my iPad On 08/02/2013, at 7:43 AM, "Kristian Lind" <klpcrap@gmail.com> wrote: In a previous project I switched from commons-logging -> log4j to sl4j -> logback. One of the reasons I did that was the overhead in log4j when providing a object in the log... log.debug("This is a object" + object); would cause the object.toString to be called even debug was not enabled. Now I work on a new project that uses commons-logging -> sl4j -> logback (jcl-over-slf4j) My question is now, will this still call object.toString.. even debug is not enabled import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; .... log.debug("This is a object" + object); I would like to get rid of commons-logging and jcl-over.sl4j and only have sl4j and logback. _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user -- Med venlig hilsen / Best regards Kristian Lind

On Thu, Feb 7, 2013 at 1:11 PM, Brett Walker <brett.walker@geometryit.com>wrote:

Log.debug("The object is {0}", object);

Are positional parameters a new feature in Logback? I just started using it and all the examples I've see use empty braces with no way to reorder the parameters via the message. In other words, I would expect to see this: Log.debug("The object is {}", object); David

On Thu, Feb 7, 2013 at 3:35 PM, Brett Walker <brett.walker@geometryit.com>wrote:

This avoids calling the toString() method on the objects until the log message is actually required to be logged.

Sorry, Brett, I changed the subject without actually changing the subject since it was semi-related. :) I was asking about "{0}" versus "{}". David

It's may bad. {} is the only syntax allowed It would be a nice addition to have positional, but how warranted is it? Brett From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of David Harkness Sent: Friday, 8 February 2013 10:46 AM To: logback users list Subject: Re: [logback-user] commons-logging -> sl4j -> logback On Thu, Feb 7, 2013 at 3:35 PM, Brett Walker <brett.walker@geometryit.com<mailto:brett.walker@geometryit.com>> wrote: This avoids calling the toString() method on the objects until the log message is actually required to be logged. Sorry, Brett, I changed the subject without actually changing the subject since it was semi-related. :) I was asking about "{0}" versus "{}". David

Nice discussion. Goes further than I had thought. This pushes efficiency even further. I like it. From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Chris Pratt Sent: Friday, 8 February 2013 10:54 AM To: logback users list Subject: Re: [logback-user] commons-logging -> sl4j -> logback I have a bit of a discussion on why a more robust formatting option is desirable. Check out http://code.google.com/p/anodyzed/wiki/Log and please feel free to ask any questions that come to mind. (*Chris*) On Thu, Feb 7, 2013 at 3:50 PM, Brett Walker <brett.walker@geometryit.com<mailto:brett.walker@geometryit.com>> wrote: It's may bad. {} is the only syntax allowed It would be a nice addition to have positional, but how warranted is it? Brett From: logback-user-bounces@qos.ch<mailto:logback-user-bounces@qos.ch> [mailto:logback-user-bounces@qos.ch<mailto:logback-user-bounces@qos.ch>] On Behalf Of David Harkness Sent: Friday, 8 February 2013 10:46 AM To: logback users list Subject: Re: [logback-user] commons-logging -> sl4j -> logback On Thu, Feb 7, 2013 at 3:35 PM, Brett Walker <brett.walker@geometryit.com<mailto:brett.walker@geometryit.com>> wrote: This avoids calling the toString() method on the objects until the log message is actually required to be logged. Sorry, Brett, I changed the subject without actually changing the subject since it was semi-related. :) I was asking about "{0}" versus "{}". David _______________________________________________ Logback-user mailing list Logback-user@qos.ch<mailto:Logback-user@qos.ch> http://mailman.qos.ch/mailman/listinfo/logback-user

Unfortunately I don't have any solid numbers. I can definitely tell you that it's significantly faster in production settings when compared to using '+' to build up logging strings, but it will definitely be slower in debug settings when reflection is used. My focus has been to make it as fast as possible under all settings, but to focus more on the production performance, since that's what affects end users the most. In my opinion the ability to leave verbose debugging messages including lots of well formatted data in the program for those times when bugs crop up in the field, without degrading performance for every other user of the system is a huge win. (*Chris*) On Fri, Feb 8, 2013 at 12:26 AM, Thorbjørn Ravn Andersen < thunderaxiom@hotmail.com> wrote:

Out of curiosity, how fast is your solution compared with the standard syntax parser? Problem with logging systems is that they have to share cpu-cycles with the main program, so they need to be fast to avoid slowing the main program down.****

** **

*From:* logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] *On Behalf Of *Chris Pratt *Sent:* 8. februar 2013 00:54

*To:* logback users list *Subject:* Re: [logback-user] commons-logging -> sl4j -> logback****

** **

I have a bit of a discussion on why a more robust formatting option is desirable. Check out http://code.google.com/p/anodyzed/wiki/Log****

and please feel free to ask any questions that come to mind.****

(*Chris*)****

** **

On Thu, Feb 7, 2013 at 3:50 PM, Brett Walker <brett.walker@geometryit.com> wrote:****

It’s may bad. {} is the only syntax allowed****

****

It would be a nice addition to have positional, but how warranted is it?** **

****

Brett****

****

*From:* logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] *On Behalf Of *David Harkness *Sent:* Friday, 8 February 2013 10:46 AM****

*To:* logback users list *Subject:* Re: [logback-user] commons-logging -> sl4j -> logback****

****

On Thu, Feb 7, 2013 at 3:35 PM, Brett Walker <brett.walker@geometryit.com> wrote:****

This avoids calling the toString() method on the objects until the log message is actually required to be logged.****

Sorry, Brett, I changed the subject without actually changing the subject since it was semi-related. :) I was asking about "{0}" versus "{}".****

****

David****

****

_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user****

** **

_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user

On Fri, Feb 8, 2013 at 12:24 AM, Thorbjørn Ravn Andersen < thunderaxiom@hotmail.com> wrote:

I think the primary focus for this facility has been raw speed.

As well it should, IMHO. The goal for me is to provide a meaningful diagnostic of what's going on without impacting the running system too much, both when logging is turned on and off.

**

In my understanding the primary usage of positional is to be able to translate sentences more fluently into another human language.

Yes, it allows the parameters in externalized messages to be reordered while translating to other languages. I think if you're going to this much trouble to produce messages for the user, they are important enough to be left on all the time. Thus, you can pay the cost to format the message up-front using a tool more suited to that task and hand them off to the logging system. I don't see a strong need for positional parameters. David

You have started on the journey which will eventually result in that you have embedded _yet_ another runtime scripting language inside your java program[1]. This is what most “I need more power from my configuration strings” end up with in my experience. At this point I think you should rethink your use-cases. What do you actually need? Would it be solvable e.g. with Groovy code in your logback configuration file instead? [1] From Wikipedia: Greenspun's tenth rule of programming is an <http://en.wikipedia.org/wiki/Aphorism> aphorism in <http://en.wikipedia.org/wiki/Computer_programming> computer programming and especially <http://en.wikipedia.org/wiki/Computer_programming_language> programming language circles that states: <http://en.wikipedia.org/wiki/Greenspun's_tenth_rule#cite_note-1> [1] <http://en.wikipedia.org/wiki/Greenspun's_tenth_rule#cite_note-graham-2> [2] Any sufficiently complicated <http://en.wikipedia.org/wiki/C_(programming_language)> C or <http://en.wikipedia.org/wiki/Fortran> Fortran program contains an ad hoc, informally-specified, <http://en.wikipedia.org/wiki/Computer_bug> bug-ridden, slow implementation of half of <http://en.wikipedia.org/wiki/Common_Lisp> Common Lisp. From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Chris Pratt Sent: 8. februar 2013 17:34 To: logback users list Subject: Re: [logback-user] commons-logging -> sl4j -> logback In my case, a positional positioning formatter is just the beginning. The most important thing is a formatter that supports reflection, since there is no other way to allow specification of nested object hierarchies without requiring the programmer to always dereference those hierarchies whether the data will be used or not. If you have to call user.getName().getFirstname() to pass to the logging system (not to mention the two '+'s you're likely to need to get it into the message) you have degraded your production performance to get the data you need to debug a potential problem in the field. If you could have specified it as ("User: {0.name.firstname} from {0.address.city}, {0.address.state}",user) it would have incurred no up front cost unless the statement was actually going to be used. The positional nature of the parameters in this case is as much about parameter reuse as it is rearranging. (*Chris*) On Fri, Feb 8, 2013 at 8:12 AM, David Harkness <david.h@highgearmedia.com> wrote: On Fri, Feb 8, 2013 at 12:24 AM, Thorbjørn Ravn Andersen <thunderaxiom@hotmail.com> wrote: I think the primary focus for this facility has been raw speed. As well it should, IMHO. The goal for me is to provide a meaningful diagnostic of what's going on without impacting the running system too much, both when logging is turned on and off. In my understanding the primary usage of positional is to be able to translate sentences more fluently into another human language. Yes, it allows the parameters in externalized messages to be reordered while translating to other languages. I think if you're going to this much trouble to produce messages for the user, they are important enough to be left on all the time. Thus, you can pay the cost to format the message up-front using a tool more suited to that task and hand them off to the logging system. I don't see a strong need for positional parameters. David _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user

Just to be absolutely clear – are you not beginning to introduce new functionality in the logging api? Something looking – for now –rather close to a subset of what the Expression Language in JavaEE applications does? There is nothing wrong with having complex logging strings, but you can do what you want in your application rather simply by mapping to {}-strings and swapping the arguments and _then_ send the result to the logging layer. (My bad about the Groovy snippets – I was thinking of logback.xml and appender layout strings (or whatever they are called today?)) From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Chris Pratt Sent: 11. februar 2013 17:18 To: logback users list Subject: Re: [logback-user] commons-logging -> sl4j -> logback Ummm, this has nothing to do with log configuration. So how would Groovy log configuration help? (*Chris*) On Feb 11, 2013 3:42 AM, "Thorbjørn Ravn Andersen" <thunderaxiom@hotmail.com> wrote: You have started on the journey which will eventually result in that you have embedded _yet_ another runtime scripting language inside your java program[1]. This is what most “I need more power from my configuration strings” end up with in my experience. At this point I think you should rethink your use-cases. What do you actually need? Would it be solvable e.g. with Groovy code in your logback configuration file instead? [1] From Wikipedia: Greenspun's tenth rule of programming is an <http://en.wikipedia.org/wiki/Aphorism> aphorism in <http://en.wikipedia.org/wiki/Computer_programming> computer programming and especially <http://en.wikipedia.org/wiki/Computer_programming_language> programming language circles that states: <http://en.wikipedia.org/wiki/Greenspun's_tenth_rule#cite_note-1> [1] <http://en.wikipedia.org/wiki/Greenspun's_tenth_rule#cite_note-graham-2> [2] Any sufficiently complicated <http://en.wikipedia.org/wiki/C_(programming_language)> C or <http://en.wikipedia.org/wiki/Fortran> Fortran program contains an ad hoc, informally-specified, <http://en.wikipedia.org/wiki/Computer_bug> bug-ridden, slow implementation of half of <http://en.wikipedia.org/wiki/Common_Lisp> Common Lisp. From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Chris Pratt Sent: 8. februar 2013 17:34 To: logback users list Subject: Re: [logback-user] commons-logging -> sl4j -> logback In my case, a positional positioning formatter is just the beginning. The most important thing is a formatter that supports reflection, since there is no other way to allow specification of nested object hierarchies without requiring the programmer to always dereference those hierarchies whether the data will be used or not. If you have to call user.getName().getFirstname() to pass to the logging system (not to mention the two '+'s you're likely to need to get it into the message) you have degraded your production performance to get the data you need to debug a potential problem in the field. If you could have specified it as ("User: {0.name.firstname} from {0.address.city}, {0.address.state}",user) it would have incurred no up front cost unless the statement was actually going to be used. The positional nature of the parameters in this case is as much about parameter reuse as it is rearranging. (*Chris*) On Fri, Feb 8, 2013 at 8:12 AM, David Harkness <david.h@highgearmedia.com> wrote: On Fri, Feb 8, 2013 at 12:24 AM, Thorbjørn Ravn Andersen <thunderaxiom@hotmail.com> wrote: I think the primary focus for this facility has been raw speed. As well it should, IMHO. The goal for me is to provide a meaningful diagnostic of what's going on without impacting the running system too much, both when logging is turned on and off. In my understanding the primary usage of positional is to be able to translate sentences more fluently into another human language. Yes, it allows the parameters in externalized messages to be reordered while translating to other languages. I think if you're going to this much trouble to produce messages for the user, they are important enough to be left on all the time. Thus, you can pay the cost to format the message up-front using a tool more suited to that task and hand them off to the logging system. I don't see a strong need for positional parameters. David _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user