Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4355453B.70302@nada.kth.se>
Date: Tue, 18 Oct 2005 20:55:55 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Problems with lazy loading components
References: <43535F3B.8040402@nada.kth.se> <435369F5.7070404@apache.org>
 <4353FFFA.7080508@nada.kth.se> <43541980.6000605@apache.org>
In-Reply-To: <43541980.6000605@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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