[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    Re: [PATCH][collections] purging reference map entries when key is
From:       "Craig R. McClanahan" <craigmcc () apache ! org>
Date:       2003-04-30 16:04:29
[Download RAW message or body]



On Wed, 30 Apr 2003, robert burrell donkin wrote:

> Date: Wed, 30 Apr 2003 13:54:01 +0100
> From: robert burrell donkin <robertburrelldonkin@blueyonder.co.uk>
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> 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 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 has the basics exactly right.

The use case we've got is a servlet container (like Tomcat) that provides
a class loader for each web application, plus a shared class loader that
is the parent of all the webapp class loaders.  For details on the
architecture, see:

  http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

With previous beanutils code (using only the static singleton), things
worked fine if you put commons-beanutils.jar in each webapp's /WEB-INF/lib
directory -- each webapp got their own copy of the singleton, with no
conflicts.  However, if commons-beanutils.jar was put in a parent class
loader (in Tomcat, by putting commons-beanutils.jar into shared/lib or
common/lib), we ran into conflicts.

The first step, as Robert points out, was to isolate the actual processing
logic of each class into a separate class that used instance methods
instead of the static ones (BeanUtils --> BeanUtilsBean and so on).  Next,
we need to work out the strategy of ensuring that each caller receives the
BeanUtilsBean instance that is appropriate for their environment.  Here is
where we need to do some interesting planning.

For a servlet container, using ThreadLocal is not the right answer,
because the container will recycle each request processing thread across
multiple webapps -- what we really want to do is allocate a BeanUtilsBean
instance per web application.  The easiest way to do that is to use the
Thread's context class loader -- this works because the container is
required to set the thread context class loader to point at the webapp
class loader before invoking the servlet to process a request.  Therefore,
we should be able to use the class loader as the key to a map to keep the
right instances.

However, we probably want to provide a strategy plugin for creating
instances -- I would advocate for the behavior described in the previous
paragraph as the default, but other strategies certainly seem feasible as
well for non-servlet-container environments.

> - robert
>

Craig

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

[prev in list] [next in list] [prev in thread] [next in thread]