Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: Classloading regression between commons-digester-1.0 and later
	versions
From: Simon Kitching <skitching@apache.org>
Reply-To: skitching@apache.org
To: Jan.Luehe@Sun.COM
Cc: Jakarta Commons Users List <commons-user@jakarta.apache.org>
In-Reply-To: <433C7645.2030407@sun.com>
References: <42C1E96D.5020301@sun.com> <433C2535.3010204@sun.com>
	 <f8b39ace050929154454809142@mail.gmail.com>  <433C7645.2030407@sun.com>
Content-Type: text/plain
Date: Sat, 01 Oct 2005 11:49:29 +1200
Message-Id: <1128124169.3855.4.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Thu, 2005-09-29 at 16:18 -0700, Jan Luehe wrote:
> Hi Craig,
> 
> Craig McClanahan wrote On 09/29/05 15:44,:
> > Hi Jan :-),
> > 
> > On 9/29/05, *Jan Luehe* <Jan.Luehe@sun.com <mailto:Jan.Luehe@sun.com>>
> > wrote:
> > 
> > 
> >     Can someone explain to me the motivation for setting the
> >     "useContextClassLoader" property to FALSE by default?
> > 
> > The motivation was this -- in a J2SE (now, Java SE) application, there
> > may not be a thread context class loader at all, or it might have
> > completely different semantics than what the EE specs require for a
> > servlet container's thread context class loader.  It seemed safer to
> > avoid potential class loading mysteries to implement this as the default. 
> 
> thanks for your reply.
> 
> Do you think it would have made sense for Digester to also consider
> a "useContextClassLoader" system property (which would be overridden
> by the Digester's "useContextClassLoader" property)?
> 
> This would allow code that runs in an EE environment and relies on
> the digester being able to load classes from WEB-INF/lib to continue
> to work with later commons-digester versions, by setting the
> "useContextClassLoader" system property to TRUE. This would be useful
> in cases where one does not have any control over the code that
> acquires a digester.
> 

It's not safe to put digester in the container path and expose this to
components. Digester uses BeanUtils which uses lots of static variables.
Any library that uses static variables is a very *bad* thing to place in
a path that is shared by multiple supposedly independent components.

I think that allowing a container to expose classes which are not part
of the container specification is a really bad idea in any case:
* http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak

Why do you have a need to expose digester to components rather than let
components which want to use digester bundle it in WEB-INF/lib
themselves?

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org