geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: NoClassDefFoundError deployment errors
Date Mon, 20 Mar 2006 18:27:38 GMT
Can you post the stack trace?  Or is it just a message?

Thanks,
    Aaron

On 3/20/06, Richard Wallace <rwallace@thewallacepack.net> wrote:
> Sorry, forgot to mention that I had tried adding the commons-logging to
> the hidden-classes.  That didn't work either.  The second configuration
> option was a no-go too, gave me the same error.
>
> Any other suggestions?
>
> Thanks,
> Rich
>
> Aaron Mulder wrote:
> > OK, then try adding the hidden classes for commons-logging too:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <web-app
> >   xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> >   configId="MPLCommon">
> >   <hidden-classes><filter>org.springframework</filter></hidden-classes>
> >   <hidden-classes><filter>org.apache.commons.logging</filter></hidden-classes>
> >   <context-root>/mpl</context-root>
> >   <context-priority-classloader>true</context-priority-classloader>
> > </web-app>
> >
> > Alternately, if that still gives you trouble, or if you want to use
> > Geronimo's commons logging instead of the one built in to your
> > application, you could try hiding the one in your application instead:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <web-app
> >   xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> >   configId="MPLCommon">
> >   <hidden-classes><filter>org.springframework</filter></hidden-classes>
> >   <non-overridable-classes><filter>org.apache.commons.logging</filter></non-overridable-classes>
> >   <context-root>/mpl</context-root>
> >   <context-priority-classloader>true</context-priority-classloader>
> > </web-app>
> >
> > I haven't seen this commons-logging problem before, but maybe it's
> > just that I haven't deployed apps that use commons-logging themselves.
> >
> > Thanks,
> >     Aaron
> >
> > On 3/20/06, Richard Wallace <rwallace@thewallacepack.net> wrote:
> >
> >> Aaron Mulder wrote:
> >>
> >>> To the original poster:
> >>>
> >>> You actually need *Spring* in your hidden classes element.  I believe
> >>> everything will work if you just list Spring alone (e.g.
> >>> org.springframework) and not Faces, Hibernate, or Commons Logging.
> >>> It's possible that you might need commons logging listed as well, but
> >>> I think once you're using the right Spring, it will get beyond the
> >>> commons logging problem.
> >>>
> >>>
> >>>
> >> So what should my geronimo-web.xml look like?  Right now I've got
> >>
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <web-app
> >>   xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.0"
> >>   configId="MPLCommon">
> >>   <hidden-classes><filter>org.springframework</filter></hidden-classes>
> >>   <context-root>/mpl</context-root>
> >>   <context-priority-classloader>true</context-priority-classloader>
> >> </web-app>
> >>
> >> And I'm still getting the commons-logging error?
> >>
> >> Thanks,
> >> Rich
> >>
> >>> To Brill:
> >>>
> >>> It wouldn't break my heart to see Geronimo default to the spec
> >>> behavior for class loading.  I'm not sure that would solve this
> >>> problem (e.g. if the class is already loaded it may not load it
> >>> *again* from the web app loader), but I'd have to check the spec to be
> >>> sure.
> >>>
> >>> To David J:
> >>>
> >>> I'd still like to see applications on a class loader that has only the
> >>> spec classes as a parent and not the Geronimo implementation classes.
> >>> That is, we have a CL with all the spec JARs, with one child for the
> >>> server code and a separate child for the application code.  Previously
> >>> I think you've said "it might work but we'd need to try it to be sure"
> >>> -- I'll try to experiment with this once the SVN tree stabilizes a
> >>> bit.
> >>>
> >>> Thanks,
> >>>     Aaron
> >>>
> >>> On 3/18/06, Brill Pappin <johnpappin@gmail.com> wrote:
> >>>
> >>>
> >>>> Isn't that non-standard?
> >>>> I mean, Geronimo should be prefering the libs in the WAR over its own
> >>>> libs. I thought that was part of the spec for webapps.
> >>>>
> >>>> I've been having the same trouble myself, and its contrary to what I
> >>>> expect having used a veriety of other app servers. Geronimo should not
> >>>> be causing my application to blow up because of library conflicts.
> >>>>
> >>>> I do think its ability to share libs easily is good, but I think the
> >>>> default should be to isolate the webapp and allow sharing to be turned
> >>>> on via the geronimo config xml file.
> >>>>
> >>>> Does anyone know why Geronimo is so loose with its classloaders? Was
> >>>> this a design choice or an artifact of some other issue?
> >>>>
> >>>> If it was a design choice, I would *really* like to see the
> >>>> justification for it... and if an artifact, it needs to be corrected
> >>>> ASAP.
> >>>>
> >>>> - Brill Pappin
> >>>>
> >>>> On 3/17/06, David Jencks <david_jencks@yahoo.com> wrote:
> >>>> [...]
> >>>>
> >>>>
> >>>>> My first guess is that a copy of spring included in geronimo is
> >>>>> getting used in your web app instead of the copy you are trying
to
> >>>>> use: when our copy tries to load the faces/hibernate classes it
can't
> >>>>> find them.  If this is the problem you should be able to fix it
by
> >>>>> adding spring and hibernate to the hidden classes list in your
> >>>>> geronimo plan for your application.
> >>>>>
> >>>>>
> >>>> [...]
> >>>>
> >>>>
> >>>>
> >>
>
>

Mime
View raw message