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
|