Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
The current behaviour is flawed as we already know from e.g. the case
with the I18N transformer where dynamic resolution is used when static
is what would have been expected. With lazy loading things get even
worse as resolution during the setup phase also can become dynamic.
It is time that we solve this problem once and for all.
Yeah, sure, I totally agree. But providing two different source
resolvers creates imho more confusion than it really helps.
And actually 3 resolvers, as we also have the one in setup() of sitemap
components :-)
Here's another suggestion that doesn't need a new component.
First of all, when a component is setup (i.e. Avalon lifecycle
interfaces), the relative path must *always* be the one where the
component is declared, whatever the current environment is. This solves
the issues with lazy loading and poolable components that are created on
demand.
Outside of the component setup, we have the current behaviour where the
relative path depends on the current sitemap.
Now if a component needs to access some resources relative to the place
where it was declared, then it *must* resolve that URI during its setup
phase.
Example:
class FooTransfomer extends... {
ServiceManager manager;
String baseURI;
SourceResolver resolver;
public void service(ServiceManager sm) {
this.manager = sm;
this.resolver = (SourceResolver)sm.lookup(SourceResolver.ROLE);
this.baseURI = resolver.resolve("").getURI();
// yeah, we must also release the source...
}
public void doSomething(String sitemapURI, String configURI) {
// Access data relative to the current sitamep
Source sitemapSrc = resolver.resolveURI(sitemapURI);
// Access data relative to the place where the component was defined
Source configSrc = resolver.resolveURI(configURI, baseURI, null);
....
}
}
You say that it's the developer who decides how sources are resolved
(what the base for relative resolving is). Now, what about having an
i18n transformer configured in the main sitemap once with all the
configuration and then the transformer is used in several sub sitemaps.
Each sub sitemaps has the same set of catalogs. So in this case, the
transformer is configured once in the main sitemap with relative paths
and the paths are resolved in a sub sitemap relative to the sub sitemap.
Hmm... although nothing requires it, URLs specified in a configuration
should always be interpreted as being relative to this configuration.
Otherwise you don't really know what data you're pointing to.
Ok, this might be a constructed case, but I think the point is, the
developer can't always decide.
So, again why not using the following:
<map:transform src="my-class">
<map:parameter name="config-file"
value="static://relativ_to_this_sitemap"/>
and
<map:transform src="my-class">
<map:parameter name="config-file" value="relativ_to_the_usage_sitemap"/>
Everything stays the way it is and you can force source resolving to be
relative to the defining sitemap by using the protocol.
Hmm... adding yet another protocol whose base URI depends on the context
doesn't go towards more simplicity. IMO the "keep the baseURI" pattern
explained above actually solves all problems *if* the relative path is
always set to the component's declaring sitemap during component setup.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
