Daniel Fagerstrom wrote:<snip/>
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 sitemap.
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 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.
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.
Agree.
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.
Ok.
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.
/Daniel
