Thanks, Simon. Much clearer now. <snip/>
> No, I mean the situation where a container continues running, while a webapp > or EJB running within it is stopped & restarted (potentially with updated > code). OK, so then lifecycle events should get triggered. <snip/> > > > Commons provides libraries that might be used in j2ee environments, or might > be used in stand-alone apps; we don't know. So we need to write code that > works well in both environments. Agreed, but I am still resisting taking more responsibility than just exposing APIs that support cleanup. > > Currently, when JCL 1.0.4 is used in a j2ee environment *and* commons- > logging.jar is deployed in a shared classloader the application (or the > container) needs to add a call to LogManager.release when the component is > stopped/undeployed. This is a bit of a nuisance. It is even more of a nuisance > if a developer hasn't actually wanted to use JCL directly, and it is there > only because they use something like commons-foobar.jar which depends upon > commons-logging. Suddenly they need to "know" to add this extra call into > their app on undeploy. It would be really nice if commons-logging would > just "do the right thing" without putting extra burden on the developer. Maybe now beaten into submission, but still wanting to respond that [foobar] should be aware of resources that it is allocating and expose its own cleanup API, which the user invokes to clean up everything that [foobar] has allocated, including releasing loggers, etc (which the [foobar] user, I agree, not have to worry about). > > If there were simply a way to create a Singleton object that would work for > stand-alone java apps *and also* work on a per-component basis in a j2ee > framework that would solve the problem. But there doesn't seem to be a way to > write a Singleton correctly without asking the *user* of a library to > explicitly know about all the singletons that the library uses internally and > to clean them up on component stop/undeploy. > But to make this work in general, we need to make sure that the lifecycle of whatever backs the singleton (in your proposed solution, IIUC a context classloader) coincides exactly with the lifecycle of all its users. I guess the vague spec passage that Robert quotes here http://jakarta.apache.org/commons/logging/tech.html#J2EE%20Context%20Classloaders means that this should work for J2EE components. Like I said, I am not questioning the value of the "ClassLoaderLocal" concept or, at the end of the day, the practicality of using this kind of thing in [logging] and [beanutils] (or other commons components that need singletons), just trying to understand better exactly what it means and the pros and cons of depending on it. Thanks for the clarification. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
