Moving libraries of web apps into shared folder

If you plan to move repeating libraries of your several web applications depend on, to a shared folder of your application server, I would definitely say NO! to this request. One of my clients asked me about to centralise such repeating libraries into a shared folder. Actually, I had written another blog post in which I mentioned about the problems that may arise, and had concluded that “it is much more preferable to keep application specific classes or jars isolated in each web application’s private classpath.” in it. However, he insisted on seeing what will happen if we try to move them out…

I mentioned to him that main problem arise with some libraries/frameworks located in common/shared folder that need to load classes/resources which need to be placed in web application specific classpath locations, either WEB-INF/classes, or WEB-INF/lib. Unfortunately, due to ClassLoader hierarchy in web containers, such libraries/frameworks could easily fail to load application specific resources/classes located in web app specific classpath locations.

Web containers use ClassLoaders as well as WebAppClassLoaders, whose behaviour is a bit different than ordinary ClassLoaders, in order to load and serve web applications deployed. Each web application has its own WebAppClassLoader and they first look at those app specific locations (WEB-INF/classes and jars in WEB-INF/lib) to load required classes/resources. They consult to their parent ClassLoader only after they fail to find them in those locations. Parent ClassLoaders show ordinary Java ClassLoader behaviour. They first ask their parent, and only if their parent returns null they will check their classpath locations. Parents will also never ask to their children to resolve classes/resources.

In the end, we have been hit by several different parts which need to load resources, located in WEB-INF/classes or WEB-INF/lib folders. One was Vaadin. It was located in shared folder, but it tried to load application specific class derived from com.vaadin.Application. Another problem arose from Hibernate and Ehcache pair. net.sf.ehcache.hibernate.EhCacheRegionFactory class which is in ehcache-core.jar tried to load ehcache.xml, located in WEB-INF/classes. Actually, those libraries should have been more careful about loading/accessing such resources/classes. However, in reality it is very easy to be hit by such a problem when you try to centralise common libraries into a shared folder. I consider that even one of the main obstacles for OSGI to be main stream was such class loading issues and incompatibilities of libraries in OSGI environments.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.