commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging, beanutils, others] Initial proposal for java.lang.ContextClassLoaderLocal or java.lang.Singleton
Date Tue, 22 Mar 2005 11:36:15 GMT
Phil Steitz <phil.steitz <at>> 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:
> >
> >
> 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 

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



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message