cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Problems with lazy loading components
Date Mon, 17 Oct 2005 21:37:04 GMT
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 Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message