Carsten Ziegeler wrote: > > ... > > > > Yes, but I think we should just either say that > > > > a) the service will not be able to resolve against the current > > sitemap context, i.e. it will be relative to the root CM. > > b) the service will not be one instance per container hierarchy > > but one instance per container so that it is local to the current > > sitemap container and receives the SourceResolver that > belongs to it. > > > > Perhaps this is a matter of defining a seperate lifestyle for b) ? > > > Ok, a) will break existing implementations (as noted) which might be > ok, but is not really a change users want to see, I guess. > I'm not sure, but if you go for b) wouldn't that mean that you > have to declare *all* components on each sitemap? > Situation: two CMs, A being the parent of B. > A: Component One - using Component Two > Component Two - using the Source Resolver (this falls into > category b > from > above) > B: Component Three - using Component One > > As Component Two uses the Source Resolver, it has to be defined > in CM B as well, so we get: > > B: Component Three - using Component One > Component Two - using the Source Resolver (this falls into > category b > from > above) > Now, Component Three looks up Component One (from CM A) and > this looks up > Component Two, also from CM A - and the source resolving doesn't work > as expected anymore. >
Yes, you are right this would lead to very unpredictable behavior indeed. So this isn't an option then. Another approach I was going to look into is the Resolvable features of the Context object. (Don't know if you are aware of this.) Right now the SourceResolverImpl class caches the context-root Context entry during the contextualize fase. The Resolvable lets you define context entries that can be resolved upon access. So this would be a nice place to put that sitemap tracking logic if that proves inevitable. Each CocoonContainer would hold a reference to its parent CocoonContainer. A CocoonContainer defines some context Resolver members such as the one for resolving context-root entries. Each time a sitemap is entered an event travels up the container hierarchy notifying all the ancestors, also supplying enough information to pass on to the Resolvers. Each CocoonContainer tells its Resolvable members that this happened and provides enough info to them to be able to do their work properly. This would not get rid of using ThreadLocal but *would* get rid of those nasty statics. -- Unico
