One of the problems you come across when using Weblogic are Weblogic classloader issues. These can regularly happen because Weblogic itself uses a lot of frameworks, some of which you’re also using in your application EAR/WAR file. Sometimes you want to use a newer version of the library then the one in Weblogic and that’s when the problems start because your library comes later on the classpath.
WLS CAT (Class Loader Analysis Tool)
Fortunately there is a Web app wls-cat available by default in Weblogic (you don’t see it deployed in the Weblogic console though).
Below you can find a screenshot of wls-cat in action. When you analyze conflicts, the tool will spit-out all classes which are in conflict – eg. more then one version is on the classpath (EAR/WAR classpath + Weblogic classpath), but only one can be loaded in the JVM.
Once you have a list of the packages/classes in conflict, you have two options: either you can remove the duplicate jar from your EAR application, or you can instruct Weblogic to choose your version over the one bundled in Weblogic.
The latter option is configured via the META-INF/weblogic-application.xml file in your EAR file:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
</prefer-application-packages>
Configuring the options happens on package level. Now the nice thing about wls-cat is, that it also generates a ready-to-use prefer-application-packages xml element so you don’t need to create this list fully by hand by inspecting all the packages inside a conflicting library jar
