Application was failing to find an application class.
Using jarscan we searched the jars containing this class from the middleware home.
The jars were present in the domain lib.
We also checked the classpath in the startWeblogic.cmd and setDomainEnv.cmd to check if direct references were present in the server classpath.
The we logged in to Weblogic Console and analyzed the classloading conflict from the classloader tool.
You can find more details here.
We kept the jar containing the class in the APP-INF lib of the EAR and added the following in the weblogic-application.xml
<prefer-application-packages> <package-name>com.demo.*</package-name> </prefer-application-packages>
Using prefer-application-packages we can ensure that our application packages are loaded and not Weblogic Server’s.
After updating the application the issue was resolved.