[logback-user] configuration through JNDI

[bjorn rohde jensen]

> On 18.06.2012 16:44, bjorn rohde jensen wrote:
>> Hi guys,
>>
>> I recently switched to logback, and im trying to use JNDI to configure
>> logback for webapps running in tomcat 6.
>>
>> What i want to do is configure logging for each webapp using a different
>> configuration file for each tomcat context. The logback configurations
>> must be external to the wars and to the tomcat installation. Furthermore
>> i cant rely on environment variables or -D options to the tomcat.
>>
>> The only solution, i have come up with so far is to pack a skeleton
>> logback configuration file in the war, which uses logbacks JNDI and
>> include mechanisms to locate and include a file containing the real
>> configuration like so:
>>
>> <configuration scan="true" scanPeriod="5 minutes">
>> <insertFromJNDI env-entry-name="java:comp/env/appName/logback"
>> as="logbackConfiguration"/>
>>
>> <include url="${logbackConfiguration}"/>
>>
>> </configuration>
>>
>> While this does work, i would prefer being able to lookup the full
>> configuration directly.
>>
>> Is there a way to do this, or could one be added?
>
> Hi Bjorn,
>
> The solution you came up iwth, that is JNDI+Include, is in my opinion
> quite good. It's the recommended approach to the problem specification
> you describe. The include mechanism is fully supported, it even works
> with auto-scan. Could you describe the alternative solution you have
> in mind?
>
> --
> Ceki
> http://twitter.com/#!/ceki

Hi Ceki,

Thank you for the quick response.

One problem with the JNDI+Include solution is, that the scan rate is 
hardcoded in the skeleton configuration file.

The two things, which would help me here, are, to have logback try to 
lookup a magic key in the JNDI directory, if JNDI is available, and 
secondly to allow the associated value to be a stringified url and not 
just a resource to be loaded from classpath.

I dont think, these two changes would cause problems for others, but i 
havent really thought this through in detail.

Yours sincerely,

Bjorn R. Jensen