EAP 6.1.0 Alpha: Using logging in a shared module
jrantav Mar 25, 2013 5:05 AMWe are having difficulties to implement logging separation with JBoss EAP 6.1 Alpha when using shared modules containing common libraries. In our scenario we have installed several shared libraries (Spring, Dozer, Logback, shared custom logic etc) as JBoss module(s) and deploying our business services as war packaged applications. War applications are using the common classes from the module libraries.
One of our requirements is that each web application should have its own logging context (logfiles, levels, log configurations etc). We have tried to follow instructions described in Logback manual (http://logback.qos.ch/manual/loggingSeparation.html) and introduced ContextJNDISelector and SiftingAppenders etc. Both applications have their own logback.xml files which are read and logback is initialized during the application deployment.
However it seems that when applications are using shared module containing logging classes, they eventually share the same classloader responsible of maintaining at least some of the logging instances (e.g. static reference to logger classes). So far we have noticed that if we deploy webapp_A and webapp_B using the same module, at least logging configurations will affect to each other (for example if we change A’s root logger level to INFO, it will affect to webapp_B also).
We suspect that this is because classloader is shared, but has anybody else solved this kind of problem? Or is there any way to enable each webapp to have own classloader instance of the libraries in module?
We have considered other logging frameworks, too, but it would seem that our usage scenario just doesn't work with JBoss modules approach. We're currently testing if the same app works as-is with Tomcat, as we're suspecting this is JBoss modules issue.
Just to confirm that it isn't about our code, we've tested with starwars reference app (https://github.com/ceki/logback-starwars) and are seeing the same problems in there too.
EDIT: we can reproduce the problem with Tomcat global classpath so JBoss modules is not to blame here. So is it fundamentally so that existing logging frameworks have to be packaged with the application?