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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
