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 -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
