geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Woldrich <d...@woldrich.com>
Subject Re: Blogged recently about NoSuchMethodError and hidden-classes attribute
Date Fri, 12 Jan 2007 09:39:24 GMT
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
>


Mime
View raw message