cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Problems with tree buiilder
Date Wed, 08 Mar 2006 07:42:01 GMT
Reinhard Poetz wrote:
> I updated SVN and tried to run the block deployment samples 
> (cocoon-deployer-webapp-sample or cocoon-deployer-plugin-demo) and get the 
> following stacktrace:
> Any ideas?
Yupp :) This is due to a change I did last week; the change is not
finished as I wanted to discuss possible solutions first here in the
list but didn't have time yet...
Now, the problem is that the code is trying to get the current bean
factory of the sitemap while the sitemap is constructed. With the "old
core", we have a fallback with the Cocoon class which calls the
enterEnvironment() method. I guess in the case of the blocks-fw you
don't have this fallback. So the workaround should be to call
enterEnvironment somewhere and but the root processor with the root bean
factory on the stack.

The problem I wanted to discuss is where to store the current bean
factory. Currently I added a getBeanFactory() method to the Processor
interface, allowing each and every processor to have an own bean factory.
An alternative would be to have this outside the processor and have a
"processor manager" kind of a class which stores the corresponding bean
factory for a processor (if it has one).

I think both solutions make sense. While the first one is easier to
implement, the second one is cleaner as it separates the concerns better.
So which way do we want to proceed? Or is there a better option?

With these changes I'm trying to reduce the impact of the internal
pipeline handling as much as possible. In the optimum case we are able
to remove the environment stack handling completly or at least make it
as small as possible.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message