Help with classloader diffs between 3.0.x and 3.2 please?

[chenis]

Hi,

I'm deploying a mock exploded ear with a common library to JBOSS - but not putting it into a xyz.ear directory - so it deploys as 3 wars (directories), and an ejb.jar (ejbs) - there is a library directory at the same level as the wars and ejb.jar directories - the files in here are referenced in the manifests. On JB 3.0.x, this configuration works great, and it allows us to re-deploy/test a single war at a time w/out having to bump the server (a 3 second cycle, vs a 2+ minute cycle)

When I move the solution to JB 3.2 - it deploys fine, but when loading the application, it throws a classloader error:

21:11:09,495 WARN at org.jboss.mx.loading.ClassLoadingTask(ClassLoadingTask.java:202) Duplicate class found: ct.org.xml.sax.SAXNotS
upportedException
Current CS: (file:/C:/_System/jboss-3.2.0/server/ecsdev2/tmp/deploy/server/ecsdev2/deploy/library/ct_xerces.jar/22.ct_xerces.jar <no
certificates>)
Duplicate CS: (file:/C:/_System/jboss-3.2.0/server/ecsdev2/deploy/library/ct_xerces.jar <no certificates>)
21:11:09,495 WARN at org.jboss.jetty.log.JBossLogSink$3(JBossLogSink.java:68) WARNING: Error for /ecs/
java.lang.LinkageError: duplicate class definition: ct/org/xml/sax/SAXNotSupportedException
at com.componentree.util.ctDocumentBuilder.getDocument(ctDocumentBuilder.java:113)
at com.componentree.util.ctDocumentBuilder.getDocument(ctDocumentBuilder.java:138)
at com.componentree.util.ctServiceLocator.initFromXml(ctServiceLocator.java:138)
at com.componentree.util.ctuServiceLocator.initInstance(ctuServiceLocator.java:152)
at com.componentree.util.ctuServiceLocator.getInstance(ctuServiceLocator.java:123)
at com.componentree.util.ctuServiceLocator.(ctuServiceLocator.java:463)
at com.sematree.ecs.util.EcsCtlet.(EcsCtlet.java:26)
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:232)
at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:176)
at org.mortbay.jetty.servlet.ServletHolder.getServlet(ServletHolder.java:275)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:333)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:192)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:129)
at org.mortbay.jetty.servlet.Default.handleGet(Default.java:274)
at org.mortbay.jetty.servlet.Default.service(Default.java:191)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
at org.mortbay.http.HttpServer.service(HttpServer.java:863)
at org.jboss.jetty.Jetty.service(Jetty.java:460)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)

The duplicate looks like the deployer is putting the jar file in the tmp directory, but also adding the native library jar files to the class path.

Is there a way to configure 3.2 so that it operates in the same classloader manner as 3.0.x ? If I move all the files into a sub-directory called xyz.ear - it deploys, and runs fine, but I lose the ability to restart individual wars w/out restarting the ear (requires toucing application.xml as opposed to web.xml in this configuration).

Any advise would be appreciated.

Thanks,

Ken

[chenis]

Perhaps my wording was too confusing to be understood in the base post - i'll try to clarify.

I'm running in a test/development environment where I have 1 EJB jar file, and 2 war files - All 3 share common libraries. When deployed as an EAR, I put the common libraries in a top level dir call 'library' and reference the 'library' in the manifest file (this is all in accordance with spec).

OK - so now when I do not package the solution as an ear, and just deploy the individual ejb jar file, and 2 war files into the jboss deploy directory - I can access the common libraries by copying the 'library' directory into the deploy directory. ex:
/deploy/library/xyz.jar and /deploy/ejb.jar and deploy/web1.war and deploy/web2.war

This works fine on 3.0.6 and 3.0.7, but throws a "Duplicate Class Definition" error on 3.2 when I go to access a class because the jar file shows up in both the 'library' directory, and a tmp/deploy/library directory (see base post for stack trace) ex:
/deploy/library/xyz.jar, /tmp/deploy/library/xyz.jar/22.xyz.jar

How should I structure the deploy directory so that multiple wars and an ejb.jar can share a common library structure in 3.2 like they can in 3.0.x without copying the files and directories into an application.ear sub-directory ? I need to be able to restart/re-init a single war w/out resarting the 330 or so EJBs.

Hopefully this makes my question easier to answer - Thanks Again ....

ken

[dsilcox69]

Just another user here....take the advise for what its worth...Two guesses for you to try..

1. Include the common library in each .war file in the lib directory. Perhaps the classloader will look there first and resolve its conflict. Build it once and "deploy" it multiple times.

2. "wrap" each .war file in a separate .ear and use the jboss-app configuration file to specify you want a separate classloader for each. I "think" the new classloader will only use the system classes if they are not found within the ear file.

[chenis]

Well, thanks for trying ... I guess there is no answer for this issue - just for clarification - i get the same problem with 1 war or 2 war the problem is with a jar that is common to the EJB's and the WAR - this jar is expanded into the tmp deployment area, and then the JBOSS classloader seems to be picking up both the one in the deploy area, and the same one it copies into the tmp deploy area and then complaining about 2 being in the path ...

The ear approach works, but then my war redeploy time is painfully slow - the idea is to run all expanded without an ear so that I can redeploy wars in a few seconds, as opposed to a few minutes with the ear approach. (the wars are accessing about 320 EJB's and it takes a little time to deploy the ejbs)

I'll stay on 3.0.7 until I figure out a way to develop with 3.2 again ...

Ken