webspherewarearopen-liberty

Open Liberty EAR Deploy: NoClassDefFoundError. Server does not load libraries in Web Application WEB-INF/lib folder

Trying to deploy a legacy enterprise application to Open Liberty 23.0.03 (until now, it was working Webshpere 8.5). The EAR structure:

EAR Structure

Starting the server and trying to inizilice spring context and servlets for the web application throws a NoClassDefFoundError for org/apache/struts/action/Action. This class belongs to the struts jar that is present only in the lib folder of the webapp, not in the root EAR lib folder.

If I put manually the struts jar in the EAR lib folder, the problem is fixed (but same error are raised for other libraries also present in webaapp lib but not in EAR lib).

Why is open libery only loading tha jars in EAR lib folder for the webapp? Until now, in Websphere, the webapp had its own library dependencies in its own WEB-INF/lib folder. Reading the servlet specification, jars in WEB-INF/lib folder should be loaded automatically for a webapp. Is it not valid in Open Liberty?

I have tried to configure enterpriseApplication element and class loader in many different ways but with no results. I'm wondering if it is mandatory in Open liberty that the jar dependencies for the webmodule are placed also in EAR lib folder.

This is the class loader configuration in WAS traditional for the application: Application class loader WAS

Solution

  • The fact that this worked with the "Single class loader for application" setting in WAS traditional indicates that the problem is a class loader hierarchy issue between the EAR and the WAR - some class in the EAR has a dependency on some class in the WAR. Typically, that packaging would not work, as the EAR loader is a parent of the WAR loaders, and parent class loaders cannot generally access classes in their children. That setting, though, avoided this issue, because it allowed the EAR and its WARs to share a single class loader, so the hierarchy was no longer important.

    The solution is going to require two steps:

    1. Determine what class in the EAR has a dependency on the class in the WAR
    2. Either move the EAR class to the WAR or the WAR class to the EAR

    (note that this process might require multiple iterations if there are many EAR->WAR dependencies)

    Which solution you choose in step 2 might depend on whether the class with the dependency is actually necessary at the EAR level, or if it's only used by the WAR and can be safely relocated. For what it's worth, moving the necessary class to the EAR is essentially what you were already doing in practice on your WAS traditional server, since everything was all shoved into one class loader.

    For step 1, depending on how that dependency is resolved, you may be able to figure out the dependency from the stack trace of the exception, although sometimes it can require a bit of trace analysis or deeper knowledge of how the dependencies fit together. If you're satisfied with the "just move it to the EAR" solution, you can skip the analysis step, since (as you've observed) you know that solution will work.