Daniel Fagerstrom wrote: > Carsten Ziegeler skrev: >> Daniel Fagerstrom wrote: > ... >>> IMO the use of both application contexts and service managers in the >>> tree processor is not such a good idea. It makes the code really hard to >>> follow, we should avoid mixed models in the same piece of code. >> Absolutely; remember :) this is the first version which aim was to "just >> work"; so removing all the Avalon based stuff should be the next step. > > Hmm, here we need to discuss what we aiming for. Replacing our own ECM > with Spring for creating Avalon components is great as we don't need to > support our own container anymore. Giving users a better possibility to > use Spring for their applications is also great. > > Giving us and them the possibility to mix Spring and Avalon setup in the > same block and even in the same component is less great IMO. I agree to "within the same component"; I don't agree totally to "within the same block" as you can use your own "legacy avalon" components in a block while adding new spring based ones. Though I agree that these are rare cases which should disappear over time.
> > It would IMO be a step forward if we could replace most uses of > Serviceable with setter injection, this would lead to components that > are easier to reuse and test. But making a mechanical replacement of > ServiceManager with BeanFactory will be much work with questionable > advantages. Agreed. > > Also Spring configurations are not exactly easier to manage than our > current configuration files, > http://svn.apache.org/repos/asf/cocoon/whiteboard/butterfly/src/java/applicationContext.xml. > > So before we run away and remove all the Avalon stuff we need to make > clear what we aiming for. Exactly - now, I think we should not convert all of our stuff; the only component I think were it makes sense to do it today is the tree processor; this would imho clean up this code and make it even more understandable for others. > Yes I know that Spring can make all kinds of things and provide a lot of > flexibility. For Cocoon core parts we should choose one style and stick > with that. Mixing styles makes the code hard to understand and support. Agreed >> I absolutely agree; I think we should move the container code out of the >> tree processor, so the tree processor is just for processing the >> pipelines and parsing *that* part of the sitemap. The container code >> will also read the sitemap, but only the components part. This requires >> to read the sitemap twice, but cleans up the concerns. WDYT? > > Agree. One possibility would be to make a component of the > SitemapLanguage.createApplicationContext method (except maybe for the > listener setup in the end). It could be BeanFactoryAware and LogEnabled, > and have the createApplicationContext method as its API. AFAICS it would > only be needed to be created if the sitemap actually contain a > configuration element. Which would make the treeprocessor container > dependent only when it needs internaly configured components. Yepp, agree; i'll have a loot at this stuff today. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
