The recent discussions about migrating to fortress lead me to think about our SourceResolver concept again.
First the current state: - The SourceResolver is an Avalon component that can be looked up everywhere you have a component manager (service manager). - The SourceResolver resolves any URI, including the cocoon: protocol. - Relative URIs are resolved to the current sitemap. - Sitemap components get a cocoon source resolver in the setup() (or act() ...) method. - The cocoon source resolver is an interface that is obsolete and is there only for compatibility. It extends the Avalon SourceResolver interface. So, a sitemap component always resolves URIs relative to it's sitemap. But in addition - if you have a usual avalon component, e.g. a ThreadSafe one that uses SourceResolver - this component resolves URIs relative to the current sitemap as well. So the current sitemap acts like a context for this component. This behaviour led to some more hacky implementations to make it work and we had to extend the ECM for this. The main problem is to determine the current sitemap. We have some thread local variables for this and a rather ugly handling for internal requests. Now, I think we can make it simpler :) a) A sitemap component gets a Cocoon source resolver anyway. We can provide in the setup() method a wrapper for the Avalon SourceResolver that knows it's sitemap. This is simply and doesn't need thread locals etc. anymore. b) The only problem lies in all this nice little thread safe components that resolve URIs relative to the current sitemap. One solution for b) is to say, relative paths are always resolved to the context directory of cocoon than we can remove a lot of the hacky things. But I fear this might break some things. So, what do you think? Carsten
