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
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=115588936827041&w=2 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"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:spring.properties"/>
</bean>
or
<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
ApplicationContext:
• 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.
WDYT?
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
