You have to find all the jars where you  have this class DataSourceDT and then have this class only load form one place. It goes with out saying that Class loading class comparison includes three attributes of Class  class name , class id  which is provided by class loader , Your Class  DataSourceDT Seems to be loaded by Different Class loaders and hence above error  is bound to happen .

thanks

Sanjay Gautam

I think you there is no direct answer but , I believe if your XSPs are using this class then probably it have had to be in the war so removing it from there might now help.  Secondly this ear , how are you deploying , I mean there is option to deploy ear in which all the ear level can access war and jar level stuff are you doing that class loading strategy ? described in this documentation  Class Loading in Widlfy  ear-subdeployments-isolated

Secondly the framework can also create the issues as they may have different class loaders strategy , I faced the similar issue in the JBPMN , SOAP WebService Work Item Handler. which uses the CXF  apis to create runtime XML/Java objects . I had to write the work Item handler totally new as the out of the box didnt used the right method provided by CXF apis.

Thanks

Sanjay Gautam

Dhaval,

   You need to make sure that you only have one JAR file that contains the class "com.myclass.report.DataSourceDT".    (inside your application or inside custom modules)

Many time it happens when with frameworks generating code at runtime and then instantiating the classes using their classloader instead of the one from one's application trails. but I can say that wildfly modular class loader still not so solid or there is not enough to the point documentations about its real functioning . I personally didnt have great fun migrating my applications to wildfly.  there are still lots of conflicts do arise.