geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: NoClassDefFoundError deployment errors
Date Mon, 20 Mar 2006 18:25:44 GMT
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