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.
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?
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().
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.
/Daniel
