cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Problems with lazy loading components
Date Mon, 17 Oct 2005 19:48:10 GMT
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.


> 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,


> - 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.


View raw message