Multiple webapps, one shared external configuration file
Hi, I stumbled upon this SO http://stackoverflow.com/questions/10465301/tomcat-war-configure-logback-to-... 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? 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. 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? PS: using the JNDI ContextSelector only seems to search in the web app itself for the config file. With kind regards Thomas Meyer
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-...
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
participants (2)
-
Ceki Gulcu -
Thomas Meyer