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 Wed, 04 May 2005 05:52:35 GMT
Daniel Fagerstrom wrote:
> 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 
> sitemap.
True. What about having an own source resolver for each block?

> Take a look at 
> o.a.c.components.treeprocessor.sitemap.SitemapLanguage.createContext(...) 
> 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.
Yes, unfortunately - this was used to pass information to the different
tree processor components.

> So there will be a kind of execution stack in the Core where the current 
>   processor (with service manager and context) is pushed?
We already have this: the environment helper.

> 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.
Perhaps we have an own container per block? I actually don't know the
answer as I don't know what blocks really are and how they could/should
work :(

Carsten Ziegeler - Open Source Group, S&N AG

View raw message