cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Context dependent thread safe componets in subsitemaps
Date Mon, 02 May 2005 18:46:11 GMT
Daniel Fagerstrom wrote:
> 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?

> 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.
What exactly do you need? The Context object or the service manager or...?

> 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.
Context is global - so the problem is "only" with service manager.

> The main alternatives AFAICS is:
> 1. Remove all uses of Serviceable and Contextualizable and get this 
> information from the EnvironmentHelper instead.
EnvironmentHelper is an internal object - I know I use it in the
SourceResolver as well, but I will change that asap. The new Core object
will provide the information soon.
In general I think we should move away (slowly!) from the Avalon interfaces.

> 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).
This doesn't help. For example all sitemap components are pooled and you
have the same problem with pooled components.

> 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.
Now, where is exactly your problem? What use-case are you trying to
solve? Until 2.1.x we have a root component configuration where *all*
components were defined. Starting with 2.2 you can define components on
a per sitemap level. Now usually these components are application
specific, so you will not run into the problems. The app specific
components lookup core components but not vice versa. The only exception
are protocols imho.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message