Return-Path: 
 <user-return-2637-apmail-geronimo-user-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-user-archive@www.apache.org
Received: (qmail 28720 invoked from network); 20 Mar 2006 18:26:36 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 20 Mar 2006 18:26:36 -0000
Received: (qmail 87929 invoked by uid 500); 20 Mar 2006 18:26:08 -0000
Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org
Received: (qmail 87877 invoked by uid 500); 20 Mar 2006 18:26:08 -0000
Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:user-help@geronimo.apache.org>
list-unsubscribe: <mailto:user-unsubscribe@geronimo.apache.org>
List-Post: <mailto:user@geronimo.apache.org>
Reply-To: user@geronimo.apache.org
List-Id: <user.geronimo.apache.org>
Delivered-To: mailing list user@geronimo.apache.org
Received: (qmail 87838 invoked by uid 99); 20 Mar 2006 18:26:08 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Mar 2006 10:26:08 -0800
X-ASF-Spam-Status: No, hits=1.4 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: 67.88.140.227 is neither permitted nor
 denied by domain of rwallace@thewallacepack.net)
Received: from [67.88.140.227] (HELO beluga.contentconnections.com)
 (67.88.140.227)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Mar 2006 10:26:05 -0800
Received: from localhost (localhost [127.0.0.1])
	by beluga.contentconnections.com (Postfix) with ESMTP id 18994C697
	for <user@geronimo.apache.org>; Mon, 20 Mar 2006 11:25:01 -0700 (MST)
Received: from beluga.contentconnections.com ([127.0.0.1])
 by localhost (mail.contentconnections.com [127.0.0.1]) (amavisd-new,
 port 10024)
 with ESMTP id 13025-08 for <user@geronimo.apache.org>;
 Mon, 20 Mar 2006 11:24:58 -0700 (MST)
Received: from [172.20.0.123] (unknown [172.20.0.123])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by beluga.contentconnections.com (Postfix) with ESMTP id 54673CC97
	for <user@geronimo.apache.org>; Mon, 20 Mar 2006 11:24:58 -0700 (MST)
Message-ID: <441EF3A8.8000908@thewallacepack.net>
Date: Mon, 20 Mar 2006 11:25:44 -0700
From: Richard Wallace <rwallace@thewallacepack.net>
User-Agent: Thunderbird 1.5 (X11/20051201)
MIME-Version: 1.0
To: user@geronimo.apache.org
Subject: Re: NoClassDefFoundError deployment errors
References: <441AF086.9090703@thewallacepack.net>
	 <6C762BDF-BD26-430F-B14A-658714B162C1@yahoo.com>
	 <5bcc1a120603172201r5947ceb6h2bff9b1f407ec0ff@mail.gmail.com>
	 <74e15baa0603200747r1775815at2d2ae7698deb7f6a@mail.gmail.com>
	 <441EEF5D.70308@thewallacepack.net>
 <74e15baa0603201012j3ddfe522vc1e5abc8f39e37de@mail.gmail.com>
In-Reply-To: <74e15baa0603201012j3ddfe522vc1e5abc8f39e37de@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at contentconnections.com
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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.
>>>>>
>>>>>           
>>>> [...]
>>>>
>>>>
>>>>         
>>