cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Context dependent thread safe componets in subsitemaps (was: Re: svn commit: r165628 - ... CocoonSourceResolver.java)
Date Mon, 02 May 2005 15:33:50 GMT
Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>  
>
<snip/>

>>I had some problems getting the root context right when working on the 
>>BlockManager which I solved by redefining the source resolver in the 
>>block manager's own service manager. So I'm interested in some more 
>>details about exactly what problem you solved and how.
>>    
>>
>With 2.2 you can define components on a per sitemap level. This includes
>own protocols. If you are doing this and at the same time use components
>defined at the "root" of Cocoon (and not in your sitemap), these
>components are not able to find your protocol. This is especially
>enoying if you use the default sitemap components like the file
>generator or xslt transformer as they are defined in the root sitemap.
>With my changes, protocols are resolved in the context of the sitemap
>where the components are used.
>  
>
Ok, I studied the code in more detail, besides merging in the excalibur 
source resolver you get the service manager from the current sitemap 
instead of from the service method, is there anything more?

>>Components that are both ThreadSafe and Contextualizable can give 
>>suprising results when defined in a parent manager and used in a 
>>subsitemap where the context is different :/
>>    
>>
>Yupp :)
>  
>
The problem I had still remain, the context from the defining sitemap 
rather than the using sitemap is still used. I could modify the code to 
use the context from the EnvironmentHelper instead.

But the question is if we should try to solve this problem at a global 
level instead. ThreadSafe components that are Contextualizable or 
Serviceable will behave in the wrong way if they depend on information 
that is changed in subsitemap context or service manager and are used at 
both defining and subsitemaps.

The main alternatives AFAICS is:

1. Remove all uses of Serviceable and Contextualizable and get this 
information from the EnvironmentHelper instead.
2. Change the behaviour of ThreadSafe so that components are singletons 
relative to a service manager instead of globaly (i.e. reused in all sub 
service managers).
3. Differ between global and local Serviceable and Contextualizable.

I would assume that alternative 2. would be simplest. It should be back 
compatible concerning correct behaviour and get rid of the suprising use 
order dependent part of the behaviour. Question is if it creates far to 
many component instances and if there are other problems.

IMO we need to do something about it, we can solve it in the way you 
did, but it should rather be a component manager than a comoponent 
concern to get the right context info. And with service managers in 
subsitemap, vpcs and blocks we will need to solve this problem in a lot 
of components.

WDYT?

/Daniel


Mime
View raw message