[logback-user] commons-logging -> sl4j -> logback

[Thorbjørn Ravn Andersen]

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 at qos.ch [mailto:logback-user-bounces at 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 at highgearmedia.com>
wrote:

On Fri, Feb 8, 2013 at 12:24 AM, Thorbjørn Ravn Andersen
<thunderaxiom at 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 at qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-user

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20130211/6fa7b847/attachment.html>