I'm experiencing
java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
during deployment to WildFly 13.0.0.Final with an application which deploys fine on Payara 4.1.2.181 and 5.181 for which I have specified
<class-loader delegate="false"/>
in WEB-INF/glassfish-web.xml
. I assume that the class cast exception is caused by a class loading issue (because two equal classes loaded by different class loaders are considered not identical) which is avoided by <class-loader delegate="false"/>
, so I assume specifying the equivalent for WildFly is the KISS solution.
There're many terms regarding the (hierarchical) use of classloader in different Java EE servers (because it's not specified by Java EE) and I started reading about WildFly's concept, however I'll express what I'm looking for in GlassFish/Payara terms: avoid the class loading delegation and take dependencies/search and load classes from the deployed WAR first.
A bloated thread in the JBoss forums about a class cast exception which didn't occur with GlassFish provides a solution which doesn't apply to my application.
Interestingly, not even excluding all transitive dependencies providing org.dom4j.DocumentFactory
which makes the app effectively non-portable between Java EE servers helps.