You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2005/05/02 16:03:07 UTC
Re: svn commit: r165628 - /cocoon/trunk/src/java/org/apache/cocoon/components/source/CocoonSourceResolver.java
cziegeler@apache.org wrote:
>Author: cziegeler
>Date: Mon May 2 06:32:24 2005
>New Revision: 165628
>
>URL: http://svn.apache.org/viewcvs?rev=165628&view=rev
>Log:
>Protocols can be defined on a per sitemap configuration
>
>Modified:
> cocoon/trunk/src/java/org/apache/cocoon/components/source/CocoonSourceResolver.java
>
>
Did you merge in the Excalibur code but without implementing ThreadSafe
or are there more changes?
I had some problems getting the root context right when working on the
BlockManager which I solved by redefining the source resolver in the
block manager's own service manager. So I'm interested in some more
details about exactly what problem you solved and how.
Components that are both ThreadSafe and Contextualizable can give
suprising results when defined in a parent manager and used in a
subsitemap where the context is different :/
/Daniel
Re: Context dependent thread safe componets in subsitemaps
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> 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.
>
Ah, ok. The stack is still managed in the environment helper - the core
will give access to some objects of the stack. Currently its just the
sitemap service manager but I want to add all objects that are currently
available using the Context object.
> 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.
>
:) Might be...
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Context dependent thread safe componets in subsitemaps
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Daniel Fagerstrom wrote:
> 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 don't think it's a right way to do it too. I'd even say that this
threadsafe/poolable in question should not see *any* components from the
subsitemap(s). It should operate as if subsitemap does not exist - otherwise
behaviour of some base application finctionality might change as soon as some
subsitemap gets deployed somewhere.
You probably can come up though with some scenarios where for a particular
request made to the subsitemap, the component should be aware of subsitemap
components. Example might be SWT looking up svg2png serializer - but that (iirc)
happens outside of contextualize()/service() and it can use another API to get
hold of current environment.
As for pluggable source resolver protocol extensions, this should probably
should proactively register themselves with source resolver, so that by
deploying a block with new source resolver protocol, it is made available to any
sitemap/block.
> 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.
Yep
> And when we get blocks with
> classloader isolation we probably will change our view on what
> contrainers should do anyway.
Agreed
Vadim
Re: Context dependent thread safe componets in subsitemaps
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
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
Re: Context dependent thread safe componets in subsitemaps
Posted by Carsten Ziegeler <cz...@apache.org>.
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?
>
> 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.
>
> 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 :(
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Context dependent thread safe componets in subsitemaps
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
<snip/>
>>The problem I had still remain, the context from the defining sitemap
>>rather than the using sitemap is still used. I could modify the code to
>>use the context from the EnvironmentHelper instead.
>
> What exactly do you need? The Context object or the service manager or...?
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.
>>But the question is if we should try to solve this problem at a global
>>level instead. ThreadSafe components that are Contextualizable or
>>Serviceable will behave in the wrong way if they depend on information
>>that is changed in subsitemap context or service manager and are used at
>>both defining and subsitemaps.
>
> Context is global - so the problem is "only" with service manager.
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.
>>The main alternatives AFAICS is:
>>
>>1. Remove all uses of Serviceable and Contextualizable and get this
>>information from the EnvironmentHelper instead.
>
> 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 there will be a kind of execution stack in the Core where the current
processor (with service manager and context) is pushed?
> In general I think we should move away (slowly!) from the Avalon interfaces.
Agree.
>>2. Change the behaviour of ThreadSafe so that components are singletons
>>relative to a service manager instead of globaly (i.e. reused in all sub
>>service managers).
>
> This doesn't help. For example all sitemap components are pooled and you
> have the same problem with pooled components.
Ok.
>>3. Differ between global and local Serviceable and Contextualizable.
>>
>
> Hmm.
>
>
>>I would assume that alternative 2. would be simplest. It should be back
>>compatible concerning correct behaviour and get rid of the suprising use
>>order dependent part of the behaviour. Question is if it creates far to
>>many component instances and if there are other problems.
>>
>>IMO we need to do something about it, we can solve it in the way you
>>did, but it should rather be a component manager than a comoponent
>>concern to get the right context info. And with service managers in
>>subsitemap, vpcs and blocks we will need to solve this problem in a lot
>>of components.
>>
>
> Now, where is exactly your problem? What use-case are you trying to
> solve?
Blocks need to be executed in an own context. VPCs also use the sitemap
local context for storing the sitemap fragment. In general, as soon as
you want your components that are defined in a (sub) sitemap being able
to access sitemap local information, they need to do that relative the
current sitemap context.
Thread safe and pooled components that are used in sub sitemaps relative
the defining sitemap will have random behaviour as soon as they use
context or service manager information that is changed in sub sitemaps.
> Until 2.1.x we have a root component configuration where *all*
> components were defined. Starting with 2.2 you can define components on
> a per sitemap level. Now usually these components are application
> specific, so you will not run into the problems. The app specific
> components lookup core components but not vice versa. The only exception
> are protocols imho.
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.
/Daniel
Re: Context dependent thread safe componets in subsitemaps
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> Ok, I studied the code in more detail, besides merging in the excalibur
> source resolver you get the service manager from the current sitemap
> instead of from the service method, is there anything more?
>
No.
>
> The problem I had still remain, the context from the defining sitemap
> rather than the using sitemap is still used. I could modify the code to
> use the context from the EnvironmentHelper instead.
>
What exactly do you need? The Context object or the service manager or...?
> But the question is if we should try to solve this problem at a global
> level instead. ThreadSafe components that are Contextualizable or
> Serviceable will behave in the wrong way if they depend on information
> that is changed in subsitemap context or service manager and are used at
> both defining and subsitemaps.
>
Context is global - so the problem is "only" with service manager.
> The main alternatives AFAICS is:
>
> 1. Remove all uses of Serviceable and Contextualizable and get this
> information from the EnvironmentHelper instead.
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.
In general I think we should move away (slowly!) from the Avalon interfaces.
> 2. Change the behaviour of ThreadSafe so that components are singletons
> relative to a service manager instead of globaly (i.e. reused in all sub
> service managers).
This doesn't help. For example all sitemap components are pooled and you
have the same problem with pooled components.
> 3. Differ between global and local Serviceable and Contextualizable.
>
Hmm.
> I would assume that alternative 2. would be simplest. It should be back
> compatible concerning correct behaviour and get rid of the suprising use
> order dependent part of the behaviour. Question is if it creates far to
> many component instances and if there are other problems.
>
> IMO we need to do something about it, we can solve it in the way you
> did, but it should rather be a component manager than a comoponent
> concern to get the right context info. And with service managers in
> subsitemap, vpcs and blocks we will need to solve this problem in a lot
> of components.
>
Now, where is exactly your problem? What use-case are you trying to
solve? Until 2.1.x we have a root component configuration where *all*
components were defined. Starting with 2.2 you can define components on
a per sitemap level. Now usually these components are application
specific, so you will not run into the problems. The app specific
components lookup core components but not vice versa. The only exception
are protocols imho.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Context dependent thread safe componets in subsitemaps (was: Re:
svn commit: r165628 - ... CocoonSourceResolver.java)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler wrote:
>Daniel Fagerstrom wrote:
>
>
<snip/>
>>I had some problems getting the root context right when working on the
>>BlockManager which I solved by redefining the source resolver in the
>>block manager's own service manager. So I'm interested in some more
>>details about exactly what problem you solved and how.
>>
>>
>With 2.2 you can define components on a per sitemap level. This includes
>own protocols. If you are doing this and at the same time use components
>defined at the "root" of Cocoon (and not in your sitemap), these
>components are not able to find your protocol. This is especially
>enoying if you use the default sitemap components like the file
>generator or xslt transformer as they are defined in the root sitemap.
>With my changes, protocols are resolved in the context of the sitemap
>where the components are used.
>
>
Ok, I studied the code in more detail, besides merging in the excalibur
source resolver you get the service manager from the current sitemap
instead of from the service method, is there anything more?
>>Components that are both ThreadSafe and Contextualizable can give
>>suprising results when defined in a parent manager and used in a
>>subsitemap where the context is different :/
>>
>>
>Yupp :)
>
>
The problem I had still remain, the context from the defining sitemap
rather than the using sitemap is still used. I could modify the code to
use the context from the EnvironmentHelper instead.
But the question is if we should try to solve this problem at a global
level instead. ThreadSafe components that are Contextualizable or
Serviceable will behave in the wrong way if they depend on information
that is changed in subsitemap context or service manager and are used at
both defining and subsitemaps.
The main alternatives AFAICS is:
1. Remove all uses of Serviceable and Contextualizable and get this
information from the EnvironmentHelper instead.
2. Change the behaviour of ThreadSafe so that components are singletons
relative to a service manager instead of globaly (i.e. reused in all sub
service managers).
3. Differ between global and local Serviceable and Contextualizable.
I would assume that alternative 2. would be simplest. It should be back
compatible concerning correct behaviour and get rid of the suprising use
order dependent part of the behaviour. Question is if it creates far to
many component instances and if there are other problems.
IMO we need to do something about it, we can solve it in the way you
did, but it should rather be a component manager than a comoponent
concern to get the right context info. And with service managers in
subsitemap, vpcs and blocks we will need to solve this problem in a lot
of components.
WDYT?
/Daniel
Re: svn commit: r165628 - /cocoon/trunk/src/java/org/apache/cocoon/components/source/CocoonSourceResolver.java
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> Did you merge in the Excalibur code but without implementing ThreadSafe
> or are there more changes?
>
Upps, yes, that's what I started with and then I changed it to the
correct behaviour. I just added the missing ThreadSafe. Thanks! :)
> I had some problems getting the root context right when working on the
> BlockManager which I solved by redefining the source resolver in the
> block manager's own service manager. So I'm interested in some more
> details about exactly what problem you solved and how.
>
With 2.2 you can define components on a per sitemap level. This includes
own protocols. If you are doing this and at the same time use components
defined at the "root" of Cocoon (and not in your sitemap), these
components are not able to find your protocol. This is especially
enoying if you use the default sitemap components like the file
generator or xslt transformer as they are defined in the root sitemap.
With my changes, protocols are resolved in the context of the sitemap
where the components are used.
> Components that are both ThreadSafe and Contextualizable can give
> suprising results when defined in a parent manager and used in a
> subsitemap where the context is different :/
>
Yupp :)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/