Peter Royal wrote:
No, if you get it working on 2.0.x, I want it patched on 2.1.x as well right away.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.
I missed that otherwise I would have changed it myself. Singleton thru static is one of the worst java anti-patterns ever.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
