Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
...
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...
Yes, you are right, the risk is to high. Also it seem to be a lot of
work to control all existing code and we don't know what users have
implemented. So we have to keep the current behaviour of the
CocoonSourceResolver. Still it sucks to have a resolver that change
behaviour form setup to component usage.
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.
Ok, I guess that we have to go for your solution of having several
variants of the source resolver:
SourceResolver.ROLE + "/static" - resolve relative to the defining
manager, and is implemented as I indicated above. We could modify
CoreComponentManager so that it automatically creates static resolver
for each manager.
SourceResolver.ROLE + "/dynamic" - resolve relative the current sitemap
and uses EnvironmentHelper.resolveURI (or something similar), undefined
and throws an exception if used when there is no current processor.
Then we should try to change all uses of the current source reolver to
the new ones and in principle deprecate the CocoonSourceResolver,
(although a warning in the documentation might be enough).
WDYT?
/Daniel
- Re: Problems with lazy loading components Daniel Fagerstrom
-
