I bet it isn't related with the context but rather the classpath hierarchy. Java infrastructure provides a mechanism (ClassLoader
) to build classpath hierarchies and Tomcat (as many other servlet containers/application servers) use that to isolate the different JARs/class folders being used in a specific application.
The root class loader is the one that has less visibility inside the hierarchy, nested class loaders can look for a class inside their scope or ask a parent class loader for it if not found. Some application servers allow to configure the class loaders to ask first the parent and then look inside their own scope if the parent can't locate it. However, a parent class loader can't never load a class from a nested class loader.
NOTE: same happens with normal files, as with your logback.xml
.
So, you have some hibernate libraries deployed in your Tomcat's lib
folder, which is handled by the root class loader in the hierarchy. When you have your logback.xml
file in that folder it actually is at the same classpath hierarchy level than your Hibernate JARs, so Hibernate (or the log mechanism being used by it) can load the file because it's within its scope.
In the other hand, the libraries used by your application (WEB-INF/lib
) are handled by a different class loader which actually is nested to the previous mentioned one. When you move your logback.xml
to your application's library folders you are actually moving it to a wider scope but, since Hibernate has been loaded by a parent class loader, it can not locate the file within its scope (remember, a parent class loader can't load classes or files from its children, just the children can ask the parent for those).