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
|