[prev in list] [next in list] [prev in thread] [next in thread]
List: jboss-user
Subject: RE: [JBoss-user] RE: Classloader issues
From: "Rod Macpherson" <rmacpherson () verilet ! com>
Date: 2003-11-26 19:37:51
[Download RAW message or body]
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:alastair.rodgers@phocis.com]
Sent: Wednesday, November 26, 2003 10:45 AM
To: jboss-user@lists.sourceforge.net
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: 'jboss-user@lists.sourceforge.net'
> 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: 'jboss-user@lists.sourceforge.net'
> > 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ϊ˝
ӆ+隊X'uH_zѢrCڛzĨ \
{*.m騭kۜ+: +azZr+y^mmz(u DLq 9QjwazZn)brAޭ( \
~{h^$,zXXh+-( ~{mXy+zlX)ߣۢǫ
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic