JBoss 3.2.2RC3 + Tomcat 5.0.9 = PortableRemoteObject ClassCa

[gturner]

I built JBoss 3.2.2RC3 from source, replaced the default jbossweb-tomcat41.sar with jbossweb-tomcat50.sar, also replaced the javax.servlet.jar with servlet-api.jar and jsp-api.jar. This slightly tweaked JBoss starts up and deploys my EAR normally. Wonderful! Thank you Remy and Scott for making Tomcat 5.0 integration seamless!

However my servlets now fail to lookup remote home interfaces at PortableRemoteObject.narrow, yet a stand-alone client (separate VM) can still narrow these remote homes just fine.

This EAR runs fine under the default Tomcat 4.1 version of JBoss 3.2.2RC3, also runs fine with 3.0.8 with Jetty or Tomcat 4, which leads me to believe it has to do with class loading in the embedded Tomcat 5 service.

I've been hunting down differences between the two jbossweb-tomcat{41,50}.sar jboss-service.xml files and their repsective MBeans. EmbeddedTomcatService MBean (4.1) has an interesting attribute, UseJBossWebLoader, which is set to true, that Tomcat5 MBean lacks, also the Tomcat5 jboss-service.xml isn't setting the Java2ClassLoadingCompliance attribute inherited from AbstractWebContainer. I tried setting Java2ClassLoadingCompliance to true and it still gives the ClassClassException. I also tried running the default tomcat41 again, setting UseJBossWebLoader to false hoping it would start failing in order to isolate the problem - no luck...

Where else can I look? Has anyone else had success with embedding Tomcat 5 on JBoss 3.2?

[gturner]

I've done some more reasearch. In my static getHome method I added the following debugging code:

Object ref = initialContext.lookup("java:comp/env/ejb/Contact");

// Debug
Class[] interfaces = ref.getClass().getInterfaces();
for (int index = 0; index < interfaces.length; index++) {
Class interface = interfaces[index];

// Skip javax.ejb.Handle interface
if (interface.toString().equals(ContactHome.class.toString()) {
log.debug("getHome: Server ClassLoader is " + interface.getClassLoader());
log.debug("getHome: Client ClassLoader is " + ContactHome.class.getClassLoader());
}
}

try {
return (ContactHome) PortableRemoteObject.narrow(ref, ContactHome.class);
}
catch (Exception e) {
log.error("getHome: Failed to narrow ContactHome", e);
}

When running the default 3.2.2RC3 Tomcat bundle (4.1), the following log messages are generated:

DEBUG ContactUtil getHome: Server ClassLoader is org.jboss.mx.loading.UnifiedClassLoader3@153c017{ url=file:/usr/local/java/jboss-3.2.2RC3/server/default/tmp/deploy/tmp64909phoenix.ear ,addedOrder=43}
DEBUG ContactUtil getHome: Client ClassLoader is org.jboss.mx.loading.UnifiedClassLoader3@153c017{ url=file:/usr/local/java/jboss-3.2.2RC3/server/default/tmp/deploy/tmp64909phoenix.ear ,addedOrder=43}

When running the rebuilt 3.2.2RC3 with Tomcat 5.0 bundle the following log messages are generated:

DEBUG ContactUtil getHome: Server ClassLoader is org.jboss.mx.loading.UnifiedClassLoader3@1d41410{ url=file:/usr/local/java/jboss-3.2.2RC3_tomcat-5.0.9/server/default/tmp/deploy/tmp38129phoenix.ear ,addedOrder=46}
DEBUG ContactUtil getHome: Client ClassLoader is WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
----------> Parent Classloader:
java.net.FactoryURLClassLoader@cee11e
ERROR ContactUtil getHome: Failed to narrow ContactHome
java.lang.ClassCastException
at com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at com.newedgenetworks.phoenix.ejb.entity.ContactUtil.getHome(DbSearchUtil.java:110)
at com.newedgenetworks.phoenix.servlet.ContactHandler.handleFind(QueryHandler.java:109)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at com.newedgenetworks.phoenix.servlet.RequestHandler.handleRequest(RequestHandler.java:370)
at com.newedgenetworks.phoenix.servlet.RequestHandler.doRequest(RequestHandler.java:226)
at org.apache.velocity.servlet.VelocityServlet.doPost(VelocityServlet.java:342)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:286)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:258)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:256)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:210)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:577)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:196)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:175)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:149)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:156)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:151)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:974)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:207)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:647)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:497)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:575)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:649)
at java.lang.Thread.run(Thread.java:534)


WebappClassLoader is a class in both versions of Tomcat (org.apache.catalina.loader.WebappClassLoader), so I think I was on to something when I mentioned the lack of UseJBossWebLoader JMX attribute in the new Tomcat5 MBean in my previous post.

What am I doing on the forums? - I should file a bug report...

[gturner]

Well I found a work-around...

My project has had the following spec-compliant layout since day one (about a year ago!):

phoenix.ear!META-INF/application.xml
phoenix.ear!META-INF/jboss-app.xml
phoenix.ear!lib/commons-lang.jar
phoenix.ear!lib/phoenix-client.jar
phoenix.ear!lib/phoenix-client.jar!com/newedgenetworks/phoenix/ejb/entity/Contact.class
phoenix.ear!lib/phoenix-client.jar!com/newedgenetworks/phoenix/ejb/entity/ContactHome.class
phoenix.ear!lib/phoenix-client.jar!com/newedgenetworks/phoenix/ejb/entity/ContactPK.class
phoenix.ear!lib/phoenix-client.jar!com/newedgenetworks/phoenix/ejb/entity/ContactUtil.class
phoenix.ear!lib/phoenix-client.jar!com/newedgenetworks/phoenix/ejb/entity/ContactValue.class
phoenix.ear!phoenix-ejb.jar
phoenix.ear!phoenix-ejb.jar!META-INF/ejb-jar.xml
phoenix.ear!phoenix-ejb.jar!META-INF/jboss.xml
phoenix.ear!phoenix-ejb.jar!META-INF/jbosscmp-jdbc.xml
phoenix.ear!phoenix-ejb.jar!com/newedgenetworks/phoenix/ejb/entity/ContactBean.class
phoenix.ear!phoenix-ejb.jar!com/newedgenetworks/phoenix/ejb/entity/ContactCMP.class
phoenix.ear!phoenix-ejb.jar!com/newedgenetworks/phoenix/ejb/entity/ContactLocal.class
phoenix.ear!phoenix-ejb.jar!com/newedgenetworks/phoenix/ejb/entity/ContactLocalHome.class
phoenix.ear!phoenix.war
phoenix.ear!phoenix.war!WEB-INF/classes/com/newedgenetworks/phoenix/servlet/ContactHandler.class
phoenix.ear!phoenix.war!WEB-INF/classes/com/newedgenetworks/phoenix/servlet/RequestHandler.class
phoenix.ear!phoenix.war!WEB-INF/jboss-web.xml
phoenix.ear!phoenix.war!WEB-INF/lib/commons-lang.jar
phoenix.ear!phoenix.war!WEB-INF/lib/phoenix-client.jar
phoenix.ear!phoenix.war!WEB-INF/lib/velocity.jar
phoenix.ear!phoenix.war!WEB-INF/velocity.properties
phoenix.ear!phoenix.war!WEB-INF/web.xml

I trimmed this listing down to only what was relevant to the stacktrace in the previous post, also note the bang (!) notation representing expansion of a jar.

Anyway, phoenix-client.jar, which contains the remote interfaces, appears in this listing more than once, first in the ear/lib and second in the war/WEB-INF/lib. I do this because occasionally I want to deploy the web app in a stand-alone servlet container. I also package the phoenix-client.jar this way because I share it with other applications.

The solution was to simply remove the phoenix-client.jar from the war/WEB-INF directory.

[jackofspades]

So removing the phoenix-client.jar from the war web-inf lib eliminated the ClassCastException? That's weird. Must have to do with the order of ClassLoader or something?