Problem: I’m using an embedded Tomcat server in an application in addition to another framework, and I get classpath errors when my application attempts to access framework components.
This problem is somewhat outside the scope of this article, but as it is a common classpath-related question, here is a brief rundown of what is causing your errors. When embedded in an application that includes another core framework such as Wicket or Spring, Tomcat will load the core class using the System classloader when starting the framework, instead of loading it from the application’s “WEB-INF/lib” directory. This is default behavior that makes sense when Tomcat is running as a standalone application container, but when embedded, it results in the resource being made unavailable to the web application. Java class loading is “lazy”, which means that the first classloader that requests a certain class owns the class for the remainder of its lifecycle. If the System classloader, whose classes are not visible to the web application, loads the framework class first, the JVM will prevent additional instances of the class from being created, causing the classpath errors. The way to get around this problem is to add a custom bootstrap classloader to your application. Configure this classloader to load the appropriate libraries on behalf of your web application, and then trigger the start-up of the rest of the application as normal. This will resolve all classloader conflicts in favor of your application.
予約受付中です。