7 Replies Latest reply on May 28, 2015 4:58 PM by sanjay05222

classloading woes!

cvandyck Jul 30, 2003 12:33 PM

My application has one .EAR file, and within it two .WAR web app directories as well as an ejb .JAR to hold all of my ejbs. The two webapps are running Cocoon, and as such they have all of the necessary Cocoon libraries in their WEB-INF/lib directories, respectively.

My EJBs need access to logkit, avalon, and an FOP library, though, in order to be able to render to PDF outside of the context of one of the Webapps (i.e. for a timed rendering, etc).

When I include these libraries for the EJBs, I get all sorts of ClassCastExceptions regarding loading of the Cocoon classes. I also tried putting the extra libraries into .EAR/META-INF/lib, because I thought this would give all webapps access to the classes, and the same error ocurred.

I emailed the Cocoon help list, and learned that even though when loading classes, if the classes are technically the same, if they come from a different classloader it can throw a ClassCastException exception, which is what is happening in my case.

I'd like to completely insulate the webapps' libraries from those of the EJBs. What is the best way to do this?

I tried setting the init-classloader parameter to true in web.xml, but this had the effect of the webapps not being able to find ANY classes or libraries deployed into WEB-INF/lib.

many thanks,
Collin

1. Re: classloading woes!

jonlee Jul 30, 2003 7:28 PM (in response to cvandyck)

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.
Actions
2. Re: classloading woes!

cvandyck Jul 31, 2003 7:40 AM (in response to cvandyck)

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.
Actions
3. Re: classloading woes!

oysteinpettersen Oct 13, 2003 1:11 AM (in response to cvandyck)

Did you ever find a cure for your problem? I am having the same problem!

Oystein
Actions
4. Re: classloading woes!

jboss234 May 27, 2015 3:27 PM (in response to oysteinpettersen)

I am getting ClassCastException for same classes.

java.lang.ClassCastException: com.myclass.report.DataSourceDT cannot be cast to com.myclass.report.DataSourceDT
    at org.apache.cocoon.www.reportadmin.xsp.ListDataSource_xsp.generate(ListDataSource_xsp.java:808)
    at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:228)
    at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:578)
- 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.

Thanks,
Dhaval
Actions
5. Re: classloading woes!

jboss234 May 28, 2015 1:26 PM (in response to jboss234)

Any suggestions
Actions
6. Re: classloading woes!

sanjay05222 May 28, 2015 4:50 PM (in response to jboss234)

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.

thanks
SAnjay Gautam
Actions
7. Re: classloading woes!

sanjay05222 May 28, 2015 4:58 PM (in response to sanjay05222)

Another suggestion is that get the source of the cocoon and debug The code arround this area

at org.apache.cocoon.www.reportadmin.xsp.ListDataSource_xsp.generate(ListDataSource_xsp.java:808)
at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:228)
- See more at: https://developer.jboss.org/message/931673?et=watches.email.thread#931673

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

Apache CXF -- Dynamic Clients

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 .

READ BELOW
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 .

thanks
Sanjay Gautam
Actions

Go to original post