cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <>
Subject Re: ClassLoaderManager and its secret life as a static
Date Mon, 17 Feb 2003 20:38:45 GMT
On Sunday, February 16, 2003, at 03:25  PM, Stefano Mazzocchi wrote:
> Peter Royal wrote:
>> On Friday, February 14, 2003, at 03:08  PM, Vadim Gritsenko wrote:
>>>> The only usage of the "singleton" piece of it is in JavaLanguage, 
>>>> which takes a parameter named 'class-loader' and will use that as a 
>>>> class name to instantiate an object that implements 
>>>> ClassLoaderManager. Then in the compose method, it appends to look 
>>>> up the ClassLoaderManager component. Catch is, the compose() will 
>>>> never do that since the parameter has a default.
>>>> This is a real drag for anyone trying to safe space by not 
>>>> duplicating cocoon.jar in the WEB-INF/lib of individual webapps 
>>>> rather putting it higher up in the classloader. You can't have two 
>>>> of the same XSP pages in each webapp.
>>>> I am going to modify my local copy to accept a null parameter on 
>>>> JavaLanguage and create a new ClassLoaderManager impl that has no 
>>>> static internal instance. I am still very curious about the 
>>>> motivations that lead to the current implementation though.
>>> Your patches will be welcome
>> I can commit them myself! ;) I made them and the XSP engine appears 
>> to be working fine (that means no weird race conditions have been 
>> found.. so far).
>> This is on the cocoon_2_0_3_branch though..  What's the policy (is 
>> there?) on changes to HEAD and the stable branch? I might just wait 
>> until we upgrade to 2.1 here internally, which might be soon since I 
>> think we're going to do soon to play with all the flow goodies.
> No, if you get it working on 2.0.x, I want it patched on 2.1.x as well 
> right away.
> I missed that otherwise I would have changed it myself. Singleton thru 
> static is one of the worst java anti-patterns ever.

I'm hesitant to change the default. I found the following in the 
"xsp-internals.xml" document:

Class ClassLoaderManagerImpl implements ClassLoaderManager in a 
singleton-like fashion that ensures that only one instance of this 
class loader exists, thus ensuring the reinstantiation mechanism works 

In the interests of not wanting to break anything, I have commited a 
"NonStaticClassLoaderManager" and modified JavaLanguage as indicated 
above. This is to the 2.0.3 branch. I will update HEAD similarly in a 

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

View raw message