cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Context dependent thread safe componets in subsitemaps
Date Wed, 04 May 2005 08:56:28 GMT
Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>  
>
>>I need the context object. Take a look at 
>>o.a.c.components.blocks.BlockManager.initialize(). I need to set the 
>>context-root to the root directory of the block to get the source 
>>resolver to work in the right way. A block is supposed to be an own 
>>isolated execution unit so it shouldn't be able to access a global root 
>>sitemap.
>>    
>>
>True. What about having an own source resolver for each block?
>  
>
Yes, I eventually solved it that way.

>>Take a look at 
>>o.a.c.components.treeprocessor.sitemap.SitemapLanguage.createContext(...) 
>>and how it is used in for giving a context to createServiceManager from 
>>build in the super class DefaultTreeBuilder.
>>
>>The context is not global, there is a sub context that extend and 
>>override the root context in each sub sitemap.
>>    
>>
>Yes, unfortunately - this was used to pass information to the different
>tree processor components.
>
>  
>
>>So there will be a kind of execution stack in the Core where the current 
>>  processor (with service manager and context) is pushed?
>>    
>>
>We already have this: the environment helper.
>  
>
I know. You said:

>EnvironmentHelper is an internal object - I know I use it in the
>SourceResolver as well, but I will change that asap. The new Core object
>will provide the information soon.
>
So my question was about if you are going to move the processor stack to
Core or what info you are going to move to Core.

>>Protocols and blocks and VPCs. We can continue with the current work 
>>around for these cases for the moment. But I don't like the fact that 
>>thread safe and poolable components that are serviceable and/or 
>>contextualizable can have runtime order dependent inconsistent behaviour.
>>
>>It shows that our current container must be modified to work together 
>>with subsitemaps and blocks.
>>
>>    
>>
>Perhaps we have an own container per block? I actually don't know the
>answer as I don't know what blocks really are and how they could/should
>work :(
>  
>
My current plan is to have a common root container with the Core, and
some basic components that are used for building sitemaps etc, that I
listed in
src/java/org/apache/cocoon/components/blocks/core-components.xconf, I
don't know if it is the right list of components yet. Then each block
has an own container that has the abovementioned common one as parrent.

For the more general issue that we have started to use hierarchial
containers for non-sitemap components, and that create complications for
thread safe and poolable components, I guess that one just must be carefull.

If there happen to be any other readers for this thread ;) the idea is
as follows: If you have a threadsafe or poolable coponent that need
access to the service manager or to the context and if you use
components or context info that is redefined in sub sitemaps, you should
probably get the service manager or context from the EnvironmentHelper
instead. By doing this the service manager and context will be used
instead of the ones from the first use.

I'm not to happy with mixing the IoC style with geting things from the
EnvironmentHelper, it doesn't exactly makes the code easier to
understand. But I guess we have to get more experience from the issues
before start to doing anything about it. And when we get blocks with
classloader isolation we probably will change our view on what
contrainers should do anyway.

/Daniel



Mime
View raw message