cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: more about properties in cocoon 2.2
Date Sun, 20 Aug 2006 17:46:34 GMT
Carsten Ziegeler wrote:
> 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.

Hackish but should work ... I will get to it tonight/tomorrow.

>> 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. 
>> WDYT?
> 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.

This is something I have no idea how to do properly. Looking at 
AbstractApplicationContext it looks like we can keep current 
CocoonBeanFactory and just use it while creating application context. 
Unfortunately there is a lot of custom lifecycle code in 
CocoonBeanFactory that I do not know how to modify (ServletContextAware 
which you mentioned, some preInstantiateSingletons method that does bean 
post processing and so on). Any guidelines?

Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message