Not sure of your full requirements, but could you solve your problem by putting all the clesses in server/instance/lib where instance is your JBoss run-time instance?
I've seen this type of problem with a few App Servers, and this tends to solve the problem (including in JBoss) but some people don't like the solution for various reasons.
jonlee, thanks for the advice. Unfortunately, I tried that already and that also did not work. Regardless, we need to be able to deploy our entire application as a single .EAR, without requiring the installer to install libraries in a separate app-server directory. Thanks though!
Someone on a mailing list advised me to try replacing logkit with log4j instead, so we might head in that direction. Many thanks.
Did you ever find a cure for your problem? I am having the same problem!
I am getting ClassCastException for same classes.
java.lang.ClassCastException: com.myclass.report.DataSourceDT cannot be cast to com.myclass.report.DataSourceDT
- See more at: https://developer.jboss.org/inbox#sthash.aOZgnePm.dpuf
Its for same class, looks like they come from a different classloader.
Application is deployed as EAR which has WAR and JAR files.
WAR module has Cocoon which uses these classes and JAR has EJB component which also use these classes.
How to fix this issue.
I dont have direct answer , but I got the similar issues while using the JBPM on Wildfly , JBPMN uses a work item component it is a java client for the CXF SOAP webservice , which use to compile the client side proxy classes in order to make the webservice call. Instead of using that Work ITem provided by them out of hte box , I had to create my own and provided my compiled and generated proxy classes in order to make the webservice call.
Another suggestion is that get the source of the cocoon and debug The code arround this area
And try to see if the in the stack where cocoon is used if they are using there own class loader and look into the apis if there are option to configure cocoon to use right class loader .
Like in CXF Apis we have apis which can control the class loader for example as below
Look at it how they have provided different options. , Probably the issue has nothing to do with Wildfly it has to do with cocoon APis .
The JaxWsDynamicClientFactory sets the Thread context ClassLoader to a new ClassLoader that contains the classes for the generated types. If you need the original ClassLoader, make sure you save it prior to calling createClien
Probably cocoon is not aware of this issue , and as i can see that it is indeed generating the xsp generated code and thats where the issue is arsiing .
you might also put this issue in cocoon framework forums as defect probably you might get some help .
Sorry it provide you some guidance if you have hit a road block .