If there happen to be any other readers for this thread ;) the idea is as follows: If you have a threadsafe or poolable coponent that need access to the service manager or to the context and if you use components or context info that is redefined in sub sitemaps, you should probably get the service manager or context from the EnvironmentHelper instead. By doing this the service manager and context will be used instead of the ones from the first use.
I don't think it's a right way to do it too. I'd even say that this threadsafe/poolable in question should not see *any* components from the subsitemap(s). It should operate as if subsitemap does not exist - otherwise behaviour of some base application finctionality might change as soon as some subsitemap gets deployed somewhere.
You probably can come up though with some scenarios where for a particular request made to the subsitemap, the component should be aware of subsitemap components. Example might be SWT looking up svg2png serializer - but that (iirc) happens outside of contextualize()/service() and it can use another API to get hold of current environment.
As for pluggable source resolver protocol extensions, this should probably should proactively register themselves with source resolver, so that by deploying a block with new source resolver protocol, it is made available to any sitemap/block.
I'm not to happy with mixing the IoC style with geting things from the EnvironmentHelper, it doesn't exactly makes the code easier to understand. But I guess we have to get more experience from the issues before start to doing anything about it.
Yep
And when we get blocks with classloader isolation we probably will change our view on what contrainers should do anyway.
Agreed
Vadim
