commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <>
Subject Re: [PATCH][collections] purging reference map entries when key is garbage collected
Date Wed, 30 Apr 2003 15:06:04 GMT

----- Original Message -----
From: "robert burrell donkin" <>
To: "Jakarta Commons Developers List" <>
Sent: Wednesday, April 30, 2003 2:54 PM
Subject: Re: [PATCH][collections] purging reference map entries when key is
garbage collected

> On Wednesday, April 30, 2003, at 02:20 PM, Juozas Baliuka wrote:
> >> <background>
> >> i'm looking into per context classloader BeanUtilsBean instances. the
> >> idea
> >> is that each web app can have it's own isolated instances (rather than
> >> singleton) return on the basis on the thread's contest classloader.
> >> </background>
> >
> > Possible I do not understan a use case, but
> > each web will  have it's own isolated instances, if  beanutils.jar is
> > cloned
> > per each WEB-INF/lib .
> > Do you want to have "global" jar loaded by single class loader, but
> > singletons per classLoader ?
> (i'll explain as well as i can: craig's the expert)
> beanutils used to use static utility classes. we've been moving the
> functionality into beans (this gives greater flexibility for users). as a
> preliminary step, the static utility classes used a proper singleton. this
> means that if beanutils are loaded by the same classloader in different
> web apps, it is possible that changes made to the beanutils settings in
> one web app may effect another.
> threads servicing different web applications should have different
> ContextClassLoaders so (as i understand it) by returning an instance based
> on the ContextClassLoaders of the thread making the call we should make
> sure that different web apps get different instances. (of course, some
> badly behaved servlet containers might confound this scheme by using
> different classloader instances without providing a good equals method.)

I do not think it is a very good workaround, I prefer not to asume
"ContextClassLoaders" is set in reusable component,
and I think  WEB-INF/lib and class loading delegation workaround in servlet
spec. is better, it isolates applications, solves version conflicts,
simlifies deployment . Do you need this stuff to save momory on server ?

> > You can use ThreadLocal, it is internaly implemented as weak map without
> > dependancy on collections.
> AFAIK ThreadLocal can only be used to store variables associated with a
> particular thread. if so, then this isn't really what we're looking for.
> (i'd be glad to be corrected if i've missed something.)

 "ThreadLocal"  instances will be created per thread not per web app, it is
not good choise for this use case.

> - robert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message