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