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 09:15:29 GMT
Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>>While working on the block architecture yesterday, I saw that most of 
>>the test cases 
>>(org.apache.cocoon.test.components.blocks.BlocksManagerTestCase) failed. 
>>The problem was that block local files where resolved in wrong context. 
>>After having controlled that nothing in the source resolution mechanism 
>>had changed since last time I run the tests, I started to suspect the 
>>lazy loading of components. After having switch to eager loading 
>>everything worked again.
>>What happens is the following: The CocoonSourceResolver resolves 
>>relative the current processor (via 
>>EnvironmentHelper.getCurrentProcessor()) if there is a current processor 
>>and otherwise relative the context root from the Avalon context. So, 
>>during eager loading of global components there is not yet a current 
>>processor, so the source reolution within the components will be 
>>relative the root context of the component manager of the component. 
>>This is the correct behaviour.
>>During lazy loading the source resolution in the component will be 
>>relative the context of the processor that it happen to be first used 
>>in. This is in general wrong and can be rather confusing and complicated 
>>to find what went wrong.
>>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.
>>Anyway, I suggest that we turn of lazy loading until we have solved this 
>As posted last week, we had several problems with lazy loading as well.
>It requires a very careful configuration of your components and if
>something goes wrong, it's rather complicated to find out what is going
We should remove lazy loading as default until these problems are solved.

>I'm actually not sure what lazy loading really gives us? Ok, Cocoon
>starts faster, but if you have just configured the blocks you need I
>think there is not really a difference. And if you need the components
>anyway, you have to wait for them to be setup - being it lazy or not.
I think we need lazy loading, if you are using a block that exposes a 
number of components (like the core block), you might only use some of 
them, in this case you get much quicker start and less resource 
requirements witj lazy loading.

>Currently, each sitemap has an own source resolver which is the
>EnvironmentHelper, so it shouldn't be that hard to add this to the
>service manager.

>But I'm not sure if this helps in all cases as
>currently sources are resolved relative to the sitemap they are used in
>and not relative to the sitemap they are defined in.
This should mainly be the case for "sitemap components", and they 
implement SitemapModelComponent and get a source resolver through the 
setup method. So for the sitemap components we allready have a working 
solution for getting source resolution relative to use instead pf 
definintion. Are there any more components that should have resolution 
relative to the use (dynamic resolution) rather than relative to the 
definition (static resolution)?

If there are more components that need dynamic resolution than the 
sitemap components we need two different mechanisms, so that the user 
can choose explicitly. The current situation is far to fragile and hard 
to understand.


View raw message