We do not use WEB-INF/lib or WEB-INF/classes to avoid this. Instead we share jars across all tiers and stipulate what jar uses what in the Class-Path for each jar we assemble. We are guaranteed that there is one and only one image of a class in the whole system and, the class loader being part of the type, there is no chance of a CCE. The only time we got bit with this is when we used a third-party package that took class names as arguments and instantiated them; it could not "see" our classes so we unzipped it, updated the manifest and re-zipped it. Problem solved. I think a lot of folks dupe classes all over the place to get things working but get bitten later.
-----Original Message----- From: Alastair Rodgers [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2003 10:45 AM To: [EMAIL PROTECTED] Subject: [JBoss-user] RE: Classloader issues I found the source of my problem. Thankfully I came across Scott's classloading debug sample in the Jboss 3.2 admin doc. This revealed that I did in fact have another copy of the class available to my web app - it had been unexpectedly included in a dependency jar in WEB-INF/lib even though that jar made no use of the package in question. Al. > -----Original Message----- > From: Alastair Rodgers > Sent: 26 November 2003 11:56 > To: '[EMAIL PROTECTED]' > Subject: RE: Classloader issues > > > > > app I get a ClassCastException doing > PortableRemoteObject.narrow() on > > the remote interface > > Sorry, I meant the Home interface. > > > > > -----Original Message----- > > From: Alastair Rodgers > > Sent: 26 November 2003 11:22 > > To: '[EMAIL PROTECTED]' > > Subject: Classloader issues > > > > > > Hi, > > > > I have a legacy EAR which is currently deployed on JBoss 3.0.8. This > > contains a WAR & an EJB JAR, and the web app invokes an EJB in the > > EJB JAR. This has always worked fine using the UCL and with Jetty's > > Java2ClassLoadingCompliance set to true. > > > > However, I now need to deploy a new EAR alongside this which follows > > J2EE packaging for libs - i.e. WAR libs are included in WEB-INF/lib > > and a Class-Path entry in the EJB JAR is used to refer to library > > JARs in the EAR. This EAR has its own classloader repository defined > > in jboss-app.xml. If I set Jetty's Java2ClassLoadingCompliance set > > to false this app > works fine. > > > > How can I deploy these two simultaneously in the same domain? I > > would like to update my legacy app so that it works with > > Java2ClassLoadingCompliance = false, so I tried repackaging my > > legacy EAR so it has its own classloader repository and uses > > WEB-INF/lib in the WAR and Class-Path in the EJB JAR for the libs. > > However, when I try to invoke an EJB from the web app I get a > > ClassCastException doing > > PortableRemoteObject.narrow() on the remote interface (see > > below). The EJB home & remote interface class files are in a > > library JAR in the root of the EAR (which is referenced from > > the EJB JAR's Class-Path entry). I have double checked that > > they are not included anywhere else. > > > > Why could I be getting a ClassCastException if I have only have one > > copy of the class? What am I missing here? Alternatively, is there > > any way I can set Java2ClassLoadingCompliance on a per app basis, so > > my legacy EAR could set it true while my new app could set it false? > > Is this a problem with the JBoss version I'm using? > > > > Any advice much appreciated! > > > > Cheers, > > Al. > > > > > > java.lang.ClassCastException > > at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narro > > w(PortableRemoteObject.java:293) > > at > > javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134) > > at > > com.phocis.corex.ejb.EJBHomeFactory.lookup(EJBHomeFactory.java:141) > > at > > com.phocis.lms.workflow.WorkflowHelper.invokeWorkflowProcess(W > > orkflowHelper.java:234) > > at > > com.phocis.lms.workflow.WorkflowHelper.executeWorkflowProcess( > > WorkflowHelper.java:202) > > at > > com.phocis.sdx.servlet.SDXController.doSendSubmit(SDXControlle > > r.java:1058) > > at > > com.phocis.sdx.servlet.SDXController.processRequest(SDXControl > > ler.java:259) > > at > > com.phocis.sdx.servlet.SDXController.doPost(SDXController.java:172) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) > > 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(WebAp > > plicationHandler.java:280) > > at > > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler > > .java:553) > > at org.mortbay.http.HttpContext.handle(HttpContext.java:1717) > > at > > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebAppl > > icationContext.java:549) > > at org.mortbay.http.HttpContext.handle(HttpContext.java:1667) > > at org.mortbay.http.HttpServer.service(HttpServer.java:862) > > at org.jboss.jetty.Jetty.service(Jetty.java:497) > > at > > org.mortbay.http.HttpConnection.service(HttpConnection.java:759) > > at > > org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:923) > > at > > org.mortbay.http.HttpConnection.handle(HttpConnection.java:776) > > at > > org.mortbay.http.SocketListener.handleConnection(SocketListene > > r.java:202) > > at > > org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289) > > at > > org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455) > > > > > NHYXuw+m>xZ*mÛ+ØjzÛy!DDÈP)rAèq zßv{Ëj) ÒËËq zØXË~zwXÏË áŠÄë^™¨¥ŠË)¢{(ç[É!gzѽæÚrCë¢ Ú: ±*.Ç¢¸ ëazZr¢æÞŠÞº ¹Ëb½àèzÈ…éiÊœæy·µêÜ× DLq 9QØ^–›¬…éi`å–'$ êÞÛiÿû(º· ~ŠàzwýÚ'j×$,²ë ®f¢–)à–+-$,²ë ®X¬¶Ë(º· ~Šàzw†Ûi³ÿåŠËl²‹«qç讧zßåŠËlþX¬¶)ßøÛË.±ê
