[logback-user] Multiple webapps, one shared external configuration file

[Ceki Gulcu]

Hi Thomas,

Comments inline.

On 6/20/2016 19:15, Thomas Meyer wrote:
 > Hi,
 >
 > I stumbled upon this SO
 > 
http://stackoverflow.com/questions/10465301/tomcat-war-configure-logback-to-use-app-name-in-path
 >
 > So is it a good idea to have multiple web apps all using the same
 > config file? What is the potential drawback of above solution besides
 > all app using the same default context?

If you package logback-classic.jar in each web-app, then logback classes 
will be loaded separately by the the class loader of each web-app. In 
other words, there will be as many logback contexts as there are web-apps.

 > The last sentence "Such involuntary sharing of the same configuration
 > by multiple repositories will result in corrupt log output." from
 > http://logback.qos.ch/manual/contextSelector.html implies some
 > problems but doesn't explain why.

Multiple FileAppender instances writing to the same log file will result 
in a corrupt log file for the simple reason that the  FileAppender 
instances do not coordinate before writing to file. The fact the 
FileAppender instances are in same or different JVMs or were loaded by 
the same of different class loaders does not change the matter. Prudent 
mode solves the problem. However, prudent add significant overhead and 
is considerably slower. See 
http://logback.qos.ch/manual/appenders.html#prudent

 > The underlying idea in log back seems to be this: Always package the
 > config file in your app, if you need a different test config also put
 > test log back config file into your test class path.
 >
 > Having multiple target environments with potentially different logging
 > requirements doesn't fit above model and it would be good to
 > externalise the log back config file. But sadly only one config file
 > is supported with a system property.

 > So what is the best solution for having multiple web apps on a tomcat
 > and having multiple target environment with potential different
 > logging requirements.
 >
 > What is a good solution pattern for this?

I think config file inclusion along with variable substitution can be 
quite useful in this context.

See
http://logback.qos.ch/manual/configuration.html#fileInclusion
http://logback.qos.ch/manual/configuration.html#variableSubstitution

In a very large project with many apps, we solved this problem as 
follows. All shared a common library which shipped a common config file. 
While all the apps included this common library and thus the same config 
file, logging config was differentiated by secondary (included) config 
files which depended on the app name.

Cheers,
--
Ceki