[logback-user] Multiple webapps, one shared external configuration file
ceki at qos.ch
Mon Jun 20 20:51:32 UTC 2016
On 6/20/2016 19:15, Thomas Meyer wrote:
> I stumbled upon this SO
> 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
> 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.
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.
More information about the logback-user