ClassLoaderManager and its secret life as a static

[Peter Royal]

Anyone know why ClassLoaderManagerImpl keeps its RepositoryClassLoader as an internal static variable? There's no history in CVS or the mailing lists to indicate and reasoning behind it.

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


--
peter royal -> [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]