commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: Classloading regression between commons-digester-1.0 and later versions
Date Fri, 30 Sep 2005 23:49:29 GMT
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


Mime
View raw message