cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: more about properties in cocoon 2.2
Date Sun, 20 Aug 2006 17:13:19 GMT
Leszek Gawron wrote:
>> Yes, I like your idea. Just one simple "include-config" and that's it.
>> And the use-default-dirs can then be used to turn off including from the
>> default location which is on by default (If the directories do not
>> exists this is not concidered an error).
>> If you want I can implement this (I would not disable the possibility to
>> do a include and include-beans in the sitemap though).
> Would be even better if you described in few words how to do it. Then I 
> would do it myself and learn a lot.
Sure. The whole code is in the SitemapLanguage class. Now, there is the
evaluation of the property-dir attribute and the like. You just have to
get all "include-config" children of the Configuration object and pass
that into the method creating the settings objects. There you read all
the property files.
The second thing is to replace the "include-config" statements with
"include" and "include-bean" elements in the Configuration object (ok,
this could be solved differently but that approach works) - this is
already done for the default locations.
And this should be more or less everything.

> For now it looks a little bit like chicken egg problem: the settings are 
> created first and then passed on as a parameter for bean factory to be 
> created. Building already a spring context you find that you need to 
> include even more properties.
> One VERY important question concerning cocoon core? Why is it based on 
> spring's BeanFactory and not on ApplicationContext? 
> I propose to switch from CocoonBeanFactory to CocoonApplicationContext. 
I'm +1 for this - the original code I wrote actually used a
CocoonApplicationContext. Daniel had some concerns about it (I think it
was mainly about too many dependencies) and we switched to the simpler
bean factory. Perhaps Daniel recalls why we switched back?

Now I had some problems with the current implementation as well, for
example ServletContextAware is not handled by the bean factory, so I
extended our CocoonBeanFactory to handle this. An application context
already provides this functionality. So, +1 for this.

Carsten Ziegeler - Open Source Group, S&N AG

View raw message