Phil Steitz <phil.steitz <at> gmail.com> writes: > > Simon Kitching wrote: > >I believe there is a way, though, that the standard Java library could > >be enhanced to make this possible. In other words, a proposal would need > >to be submitted as an enhancement to java via the Java Community > >Process. Could people please have a look at this and tell me whether > >they think I'm right or that they think I'm nuts? > > > >The doc is here: > > http://www.apache.org/~skitching/ContextClassLoaderLocal.html > > > I don't claim to be an expert on any of this and I have not followed all > of the JCL and BeanUtils threads, so take these as comments from the > peanut gallery. I like the idea in the proposal, but I am not sure that > the specific application is separating concerns correctly. Maybe > answering the questions below will help me understand what is going on. > > The doc and your previous posts refer to "deployment" and "undeployment" > as the events leading to initialization and cleanup. This sounds funny > to me, because these are relatively rare events - when new or modified > components are deployed to the server or components are removed. I > assume that what you really mean is container startup / shutdown > events. Am I correct here?
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). Repeatedly stopping/starting a component happens during development. There have also been a number of logging users that have encountered this problem; I presume they have valid reasons for wanting to restart a component often though I'm not aware exactly what those are. J2EE containers are explicitly designed to allow multiple (almost) independent apps to run concurrently. Restarting the container will of course cause an outage for every app/component deployed within the container. The goal is that when a component is stopped, all memory associated with that component is made available for garbage-collection. Currently this doesn't happen under some circumstances, so stop/start done repeatedly will eventually lead to an out-of-memory situation for the JVM thereby killing the entire container. > Assuming startup/shutdown is what we need to worry about, then whether I'm not concerned about container restart; sane operating systems clean up processes pretty well. > > I can see the general value of the ContextClassLoaderLocal concept, but > I am not sure that for things like BeanUtils instance isolation in J2EE > containers this is the best way to go. What I am struggling with is why > in a J2EE container environment we would not just use JNDI or servlet- > or EJB-local references to house the singletons and lifecycle events to > initialize and clean them up. 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. 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. 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. I hope this is clearer.. regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
