David,
Well, I'm running my app with Geronimo 1.1, so I don't know if
inverse-classloading will work better with Geronimo 2.0. I briefly
tried to work with Geronimo 2.0 M1, but not having an Eclipse plugin for
it yet was really slowing me down so I went back to 1.1. I'm running
Geronimo atop Sun Java 1.5.0_09.
I was just trying to use inverse-classloading on my Enterprise App, EJB,
and Web App, I did not change any appserver settings. I tried
combinations of settings changes on all three or just the EJB (where the
JAX-WS code is actually run). My final solution was to use
<hidden-classes/> on just the EJB and leave everything else unchanged
and to remove all extra jars I had placed on the Geronimo classpath.
With <hidden-classes/>, I can deploy my CardMeeting.ear to a completely
virgin install of Geronimo and it just works. Beautiful!
As a test, I just recompiled my code with <inverse-classloading/> turned
on and <hidden-classes/> turned off on the EJB. Here's the exception
that was thrown as the app init'ed:
00:34:34,859 ERROR [[/thirdparty]] Exception sending context
initialized event to listener instance of class
com.sun.xml.ws.transport.http.servlet.WSServletContextListener
WSSERVLET11: failed to parse runtime descriptor:
java.lang.LinkageError: loader constraints violated when linking
javax/xml/namespace/QName class
at
com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:103)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3727)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4162)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.access$201(GeronimoStandardContext.java:67)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:337)
at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at
org.apache.geronimo.tomcat.GeronimoStandardContext.start(GeronimoStandardContext.java:192)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at
org.apache.geronimo.tomcat.TomcatContainer.addContext(TomcatContainer.java:313)
at
org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$9e5e5115.addContext(<generated>)
at
org.apache.geronimo.tomcat.TomcatWebAppContext.doStart(TomcatWebAppContext.java:448)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540)
at
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374)
A similar exception, but completely different stacktrace is produced
when <inverse-classloading/> turned on on the enterprise app.
The layout of jars in my application is significant and may have
contributed to the problems I was seeing with <inverse-classloading/>.
In terms of folder structure, my EAR looks like this:
CardMeeting.ear/
commons-sandbox-id.jar
quartz-1.5.2.jar
commons-lang-2.1.jar
commons-io-1.2.jar
commons-codec-1.3.jar
backport-util-concurrent-2.2.jar
DCardsJaxb.jar
DCardsServer.jar
DCardsUtil.jar
DCardsThirdParty.jar
DCards.jar
DCardsServerTransport.jar
DCardsWeb.war
DCardsThirdPartyWeb.war
DCardsServerEjbClient.jar
DCardsServerEjb.jar
META-INF/
MANIFEST.MF
geronimo-application.xml
application.xml
lib/
jaxb-api.jar
jaxws-tools.jar
streambuffer.jar
jaxws-rt.jar
jaxws-api.jar
jsr173_api.jar
activation.jar
http.jar
saaj-impl.jar
ant-junit.jar
resolver.jar
jsr250-api.jar
jsr181-api.jar
saaj-api.jar
FastInfoset.jar
stax-ex.jar
jaxb-impl.jar
sjsxp.jar
All of the jars and wars in the root folder are the utility jar projects
and J2EE deployment units that I build in eclipse. All of the jars in
the lib folder are shared library jars that the J2EE deployment units in
the ear (DCardsWeb.war, DCardsThirdPartyWeb.war, and
DCardsServerEjb.jar) reference with their MANIFEST.MF. Perhaps
<inverse-classloading/> is not correctly handling jars in the manfest
classpaths of the WAR's and EJB JAR's?
Anyhow, <hidden-classes/> is a much better solution than
<inverse-classloading/> ever was. I don't want to invert the
classloader delegation because most of the time the priorities are
correct - but being able to SELECTIVELY mask off parent classloaders and
just for particular packages, now that's progress! It's like upgrading
from a Atari 2600 to a Colecovision, everything's just better. :) I'm
just curious if Geronimo is unique in that little capability, I'm going
to have to do a little research.
Cheers,
Dave
David Jencks wrote:
Thanks for the link! Glad you got it working.
I'm wondering about your experience with <inverse-classloading/> --
did you only change that in your app or in some parts of geronimo as
well? Do you have some j2ee spec jar type classes such as servlet api
or something in your jar? I'm having trouble imagining how
inverse-classloading led to problems without one of these other
features:-)
thanks
david jencks
On Jan 11, 2007, at 11:43 AM, David Woldrich wrote:
Hi all,
I blogged recently about resolving my NoSuchMethodError and thought
you would enjoy reading about my experiences using Geronimo for my
app, CardMeeting (http://cardmeeting.com). Geronimo continues to
impress me, can't wait for Eclipse support for 2.0 so that I can
upgrade.
Here's the blog entry permalink:
http://cardmeeting.com/blojsom/blog/cardmeeting/2007/01/10/J2EE-Geronimo-hate-love-relationship.html
Cheers,
Dave Woldrich
