commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: [logging, beanutils, others] Initial proposal for java.lang.ContextClassLoaderLocal or java.lang.Singleton
Date Thu, 24 Mar 2005 00:23:09 GMT
On Wed, 23 Mar 2005 14:08:37 +0000 (UTC), Simon Kitching
<s_kitching@yahoo.com> wrote:

> Phil Steitz <phil.steitz <at> gmail.com> writes:
> 
> >
> > Thanks, Simon.  Much clearer now.
> 
> Well, that´s unfortunate, because I think I completely stuffed up the
> explanation :-(. I wrote that in an airport travel lounge after a 10-hour
> flight and in retrospect should have waited until my mind was clearer. The info
> wasn´t exactly wrong, but didn´t address the bigger picture.
> 
> So sorry for the previous post, and this is what I think I should have said the
> first time:
> 
> Library code may wish to use singletons. And that library may be used in either
> stand-alone apps or deployed within a container. The obvious singleton
> implementation (using a static field on a class) works fine for:
>  (a) standalone apps that don´t mess with classloaders
>  (b) components deployed within containers where child-first classloading
>      is done and all the necessary libs are bundled with the deployed component.
> 
> Personally, I think (b) should be *compulsory* for all container frameworks,
> and that we should simply declare that anyone who uses a commons library in an
> environment that breaks that rule will get what they deserve.
> 

For review, (b) is *not* required by the J2EE specifications -- it is
only *allowed* as an option.  I articulated the security concerns
related to this in a previous response.

> However there *are* a number of major containers which *do* break this rule by
> default. IBM Websphere is one; Resin is another. Even Tomcat provides an
> *option* to do parent-first classloading (though it´s not the default) and
> Tomcat documentation appears to encourage people to put jars in the shared/lib
> dir.

And there's a *reason* to put things in shared/lib that has a direct
impact to what the term "singleton" means in the context of a servlet
container.

As you point out, you can put your JARs in each webapp that uses them,
and not in the shared area, and not have memory leak problems on app
restart.  Instead, you'll potentially have a different problem --
increased memory consumption because each webapp creates their own
copy of every class (so "singleton" means "singleton per webapp").

If you put a JAR in shared/lib, and a class in that JAR declares a
static variable, you will end up with *one* copy of that variable
across *all* web applications -- in other words, it truly is a
singleton.  If that meets your needs, you have just saved a lot of
memory compared to allocating a copy of the static per webapp, but you
can cause yourself other grief:

* You can't reload it dynamically (again, at least in Tomcat -- this would
  require reloading all the applications anyway, so you might as well
  restart the app server).

* You might be sharing information across webapps when you do not
  want to.  Let's say, for example, that you are using a C-L Log instance
  named "com.mycompany.foo" in two different webapps.  If there's really
  only a single instance, then you can't configure it differently for the
  two apps -- only one configuration can be used.

Using a map keyed by context class loader (which is explicitly
required in the J2EE spec)  lets you have shared code (saving memory),
but still a per-webapp singleton where needed -- as long as you
remember to clean up after yourself.  Note that Struts 1.3 (and Shale)
both clean up C-L for you -- indeed, it makes sense to have your
favorite framework do this for libraries that it uses itself, or knows
will be used by the application.

There is no one univerally "right" answer, so it is important that a
library adapt to varying requirements.  But you'd better know what
your library expects when you use it in various requirements; and, to
make that easier, the library should prominently describe its own
requirements.  That is why the current efforts in documenting C-L (and
sample code for the scenarios) will be helpful.

Craig

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