cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Dependency on WebApplicationContext
Date Mon, 27 Feb 2006 08:59:37 GMT
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/

Mime
View raw message