commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [PATCH][collections] purging reference map entries when key is garbage collected
Date Wed, 30 Apr 2003 12:54:01 GMT
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 a
>> 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.)

> 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.)

- robert


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


Mime
View raw message