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 aphorism in computer programming and especially programming language circles that states:^[1][2]

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of 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