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 12:58:41 GMT
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>>> For me the property-dir attribute smells a little bit. 
> Yepp.
>>> +1 for removing
>>> it completly. I wanted to propose some kind of map:include. That would 
>>> fix another bug I mentioned lately (mvn cocoon:deploy jetty:run does not 
>>> pick up local properties for tested block):
>>> <include-props 
>>> dir="file:/c:/dev/projects/donnelley/donnelley-admin-block/src/main/resources/META-INF/properties/"/>

>>> <include-beans 
>>> dir="file:/c:/dev/projects/donnelley/donnelley-admin-block/src/main/resources/META-INF/spring/"

>>> pattern="*.xml"/>
>>> I assume property placeholders will be properly resolved as long as I 
>>> include properties first before beans (or maybe it does not matter in 
>>> current implementation)?
> It should not matter :)
>> Maybe we could just go for:
>> <include-config dir="somedir/"/>
>> instead of:
>> <include dir="somedir/legacy/xconf/"/>
>> <include-props dir="somedir/properties/"/>
>> <include-beand dir="somedir/spring/"/>
> 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.

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? Seems like my 
problem that I reported at is 
not caused by classpath issues but by the fact that BeanFactory does not 
automatically apply declared BeanFactoryPostProcessors. This means that 
the standard functionality that almost every web application has like:

<bean id="placeholderConfig"
    <property name="location" value=""/>


> <bean id="autoProxyCreator" class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
> 	<property name="interceptorNames">
> 		<list>
> 			<idref local="matchAllTxInterceptor"/>
> 		</list>
> 	</property>
> 	<property name="beanNames">
> 		<list>
> 			<value>*Service</value>
> 			<value>*ValueList</value>
> 		</list>
> 	</property>
> </bean>

will simply not work.

There are even more crucial differences between BeanFactory and 

• MessageSource, providing access to messages in i18n-style
• Access to resources, such as URLs and files
• Event propagation to beans implementing the ApplicationListener interface

The spring docs state:

"As the ApplicationContext includes all functionality of the 
BeanFactory, it is generally recommended that it
be used over the BeanFactory, except for a few limited situations such 
as perhaps in an Applet, where memory
consumption might be critical, and a few extra kilobytes might make a 
difference. The following sections
described functionality which ApplicationContext adds to basic 
BeanFactory capabilities."

I propose to switch from CocoonBeanFactory to CocoonApplicationContext. 

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