On Wed, 23 Mar 2005 14:08:37 +0000 (UTC), Simon Kitching <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
