Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of bruce.snyder@gmail.com
 designates 72.14.204.205 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=IdKmnN0e2CPRUzGiVGFb6b0x+OKpsgV3a5YSAsLRSnnk7g2zH8qCZOsjRktZSVKxY1iLA5YHWt1GDPnke317QPpveYDahoqrmBGJ48pBhHgNt+KI/tA3DcfDl+97yacZenVxbLmyo+ZKQNchm6z5w1xmDv7lZt1MUQqb+GUT91I=
Message-ID: <7b3355cb050929124341d88c7c@mail.gmail.com>
Date: Thu, 29 Sep 2005 13:43:48 -0600
From: Bruce Snyder <bruce.snyder@gmail.com>
Reply-To: Bruce Snyder <bruce.snyder@gmail.com>
To: dev@geronimo.apache.org, Kevan Miller <kevan.miller@gmail.com>
Subject: Re: [jira] Updated: (GERONIMO-518) Deploying Struts app fails on
 Logging ClassCastException
In-Reply-To: <b8b1243f0509270945762d813a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <640914344.1102300702638.JavaMail.apache@nagoya>
	 <1762927199.1127835052895.JavaMail.jira@ajax.apache.org>
	 <50137.12.17.202.43.1127836413.squirrel@mirage.savoirtech.com>
	 <b8b1243f0509270945762d813a@mail.gmail.com>

On 9/27/05, Kevan Miller <kevan.miller@gmail.com> wrote:
> Good point. I didn't notice that they were including Commons in their
> WEB-INF/lib. I think this is related to the context-priority-classloader
> discussion I brought up last week.
>
>  Section 9.7.2 of the Servlet spec specifies that for a J2EE product "The
> container should not allow applications to override or access the
> container's implementation classes". Depending on your definition of
> "implementation classes", Geronimo's servlet classloaders permit a number=
 of
> "implementation classes" (including commons-logging) to be loaded from th=
e
> web app's context. As this situation points out, this can lead to a numbe=
r
> of problems.

The same section of the same spec also states the following:

'It is recommended also that the application class loader be
implemented so that classes and resources packaged within the WAR are
loaded in preference to classes and resources residing in
container-wide library JARs.'

Tomcat is a good exmaple of this in that it provides each webapp its
own class loader. And therein lies the reason I have always
recommended that each webapp should handle it's own logging (i.e.,
contain it's own logging jars and configuration files) *completely
separate* from the app server. I've seen far too many webapps that
utilize the app server's logging mechanism for an individual webapp.
IMO, this is simply wrong becuase it's using what I consider to be a
side effect as a feature.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=3D6-E+G-N>61E<D\!G;6%I=
;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/