cocoon-dev mailing list archives

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

I need the context object. Take a look at 
o.a.c.components.blocks.BlockManager.initialize(). I need to set the 
context-root to the root directory of the block to get the source 
resolver to work in the right way. A block is supposed to be an own 
isolated execution unit so it shouldn't be able to access a global root 

>>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.

Take a look at 
and how it is used in for giving a context to createServiceManager from 
build in the super class DefaultTreeBuilder.

The context is not global, there is a sub context that extend and 
override the root context in each sub sitemap.

>>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.

So there will be a kind of execution stack in the Core where the current 
  processor (with service manager and context) is pushed?

> 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.
> Hmm.
>>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?

Blocks need to be executed in an own context. VPCs also use the sitemap 
local context for storing the sitemap fragment. In general, as soon as 
you want your components that are defined in a (sub) sitemap being able 
to access sitemap local information, they need to do that relative the 
current sitemap context.

Thread safe and pooled components that are used in sub sitemaps relative 
the defining sitemap will have random behaviour as soon as they use 
context or service manager information that is changed in sub sitemaps.

> 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.

Protocols and blocks and VPCs. We can continue with the current work 
around for these cases for the moment. But I don't like the fact that 
thread safe and poolable components that are serviceable and/or 
contextualizable can have runtime order dependent inconsistent behaviour.

It shows that our current container must be modified to work together 
with subsitemaps and blocks.


View raw message