Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
<snip/>
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?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.
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.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 :)
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
