[logback-user] Richer logconfiguration naming scheme

David Roussel nabble at diroussel.xsmail.com
Tue Apr 12 09:35:09 CEST 2011

That's an interesting approach. But it quite specific. In my world we have dozens of programs each with their own logback.xml file. Host, user or environment does't matter. 

What we do is put the logback.xml in a java package. Then at application startup we find the current main package, check logback.xml exist at that location and if so sets logback.configurationFile system property. 

Of course that suits us, but not others. Perhaps there is a more general approach?

How about this:
- at startup logback checks the logback.configurationFile sys prop. 
- if it contains any ${variables} replace them like would be done inside logback.xml itself. 
- continue startup

With this approach you could emulate the lift approach just by setting one system property. 

Optional improvements:
- include env vars as well as sys props
- allow defaults to be specified like this ${variable:default}
How does that sound?


On 11 Apr 2011, at 15:00, Urs Peter <peter.urs at gmail.com> wrote:

> Hi all,
> Recently I was reinventing once more a strategy to deal with different
> logging configurations based on environment. Logback offers a rather
> rigid approach by means of the -test naming scheme, which provides me
> with two options for logging configuration: one for real and one for
> test. For my usage, I'm looking for a richer naming scheme.
> Since I recently did some stuff with lift where they - in my eyes -
> found an elegant way to tackle this problem, I thought it might be
> handy to port this to logback. What lift does is the following: They
> use a naming scheme, which combines a run mode, and/or current user
> and/or host. Their convention looks as follows:
>> modeName.userName.hostName.props
>> examples:
>> jack.aserver.props
>> test.jack.aserver.props
>> production.aserver.props
>> staging.jack.props
>> test.default.props
>> default.props
> The run mode (test/production/staging etc.) is nothing else than an
> JVM argument (-Drun.mode=test). The current user is related to the
> user.name default JVM argument.
> What do you guys think, would this be an interesting feature?
> Cheers Urs
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-user/attachments/20110412/172087f6/attachment.html>

More information about the Logback-user mailing list