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?
Mmmh... what if a ThreadSafe component declared in cocoon.xconf expects an URI (a string) and then uses the Avalon resolver to get a Source? What base URI will be considered?
I'm not sure we can avoid keeping the current base URI in a ThreadLocal.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
