You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Peter Royal <pr...@apache.org> on 2003/02/14 18:30:12 UTC
ClassLoaderManager and its secret life as a static
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 -> proyal@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ClassLoaderManager and its secret life as a static
Posted by Vadim Gritsenko <va...@verizon.net>.
Peter Royal wrote:
> On Friday, February 14, 2003, at 03:08 PM, Vadim Gritsenko wrote:
>
>>> 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).
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=102943823815046&w=2
Ummm... My bad... Welcome back!
> This is on the cocoon_2_0_3_branch though.. What's the policy (is
> there?) on changes to HEAD and the stable branch?
If you are confident about the patch, and it fixes a problem / bug, then
commit to both branches. New features usually go to HEAD and some time
later make it into branch (example: treeprocessor, inputmodules, portal fw).
And don't forget changes.xml :)
Vadim
> 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.
> -pete
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ClassLoaderManager and its secret life as a static
Posted by Peter Royal <pr...@apache.org>.
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
properly.
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
bit.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ClassLoaderManager and its secret life as a static
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ClassLoaderManager and its secret life as a static
Posted by Peter Royal <pr...@apache.org>.
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.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: ClassLoaderManager and its secret life as a static
Posted by Vadim Gritsenko <va...@verizon.net>.
Peter Royal wrote:
> 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.
It starts from here:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/org/apache/cocoon/components/classloader/Attic/ClassLoaderManagerImpl.java?rev=1.1&content-type=text/vnd.viewcvs-markup
I guess only Giacomo knows.
> 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
Vadim
> -pete
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org