Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
...
I think the main problem is that we have a global source resolver
and try to get the context right during resolution in a smart and
subtle (and fragile) way. If we instead create one source reolver
within each service manager all source resolution within a specific
service manager will be relative to the context of the service
manager irrespectible of when the resolution is done, whether it is
eager or lazy. It will also simplify the architecture, and maybe we
could get rid of the source resolver from the Processor interface.
I already proposed a solution for this in "multi-relative source
resolving" [1]. We need two source resolvers:
- the current one, which is always relative to the current sitemap.
- another one per service manager, permanently attached to the
context where the service manager was created.
That's this second resolver that has to be used to access sources
defined by the context where the component is declared (message
dictionaries in the case of i18nTransformer). I proposed in the
original post to store the "manager-relative" resolver in the
Context, but finally think this is a bad idead, and that it should go
in the ServiceManager.
Agree.
Now most use cases don't really need to care about choosing one or
the other resolvers if we consider the following definition of the
relative context:
- during the component setup phase, sources are relative to the
location where the service manager holding the component is defined,
Yes.
- during the component usage phase, sources are relative to the
current sitemap location.
Not certain about this. I would find it more natural to always resolve
relative the service manager. For sitemap components, we want dynamic
(realtive to the current sitemap) resolution, but that is already
solved with the setup method for the SitemapModelComponent.
Currently, both the resolvers (in setup() and in the manager) use the
same base URL. I'm afraid that changing this would break a lot of things...
Note that there's nothing new here, as this is what everybody
expects, but not always happen...
Are there any "non-sitemap" components that depend on dynamic resolution?
Not easy to say, and we'll have to check all calls to resolveURI() to
know exactly...
How to implement this? CoreServiceManager needs to keep it's
location, and ComponentFactory has to set it as the base location
when entering newInstance() and restore the previous one on exit.
That should be pretty much all.
The location of the CoreServiceManager can be set as context-root in
the Avalon Context used for creating the manager. Then one add a local
SourceResolver to the manager, that will get its root-context from the
Context of the manager. Then everything else will happen
automatically, no need for changing newInstance().
Right, if we consider that SourceResolver.ROLE has a fixed base URL. But
again, I'm afraid this will break a lot of things.
This will also work with the Swing<->Avalon bridge if we do the same
context switch around ApplicationContext.getBean().
Now there are still some use cases where a component needs to access
the manager-relative resolver in the usage phase. It's again the
i18nTransformer that does some lazy loading of dictionaries. For
these cases, we can have a specific variant of the SourceResolver
role that's always bound to the service manager. To load dictionaries
relative to its configuration location, i18nTransformer would then
lookup e.g. SourceResolver.ROLE + "/manager".
Hmm, think this should be the normal behaviour and that we should have
a special mechanism for dynamic resolution, like
EnvironmentHelper.resolveURI.
Of course, if there are several components that depends on dynamic
resolution I have to think more.
Hmm... (light bulb!) or even maybe not if it uses its configuration
location as the base URL for loading dictionaries!!!!! We tend to
forget the 3-parameters variant of SourceResolver.resolverURI() which
allows to specify the base URL!
Yes, or having static resolution (relative to the location of the
service manager) as default.
Anyway, I suggest that we turn of lazy loading until we have solved
this issue.
I consider lazy loading an indicator of source resolving flaws and a
good motivation to fix it for good :-)
So do I, but we don't need to have it brooken and hacking around its
consequences while discussing how to solve it. Please revert to eager
loading as default until this is solved.
Done. But it will be back!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
