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 Fri, 14 Feb 2003 20:18:07 GMT
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.

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

View raw message