Broadleaf provides a powerful context merge process that happens on app startup. For example, we define the following bean in a Broadleaf JAR:
Code: Select all
<bean id="blWebTemplateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine">
<property name="templateResolvers">
<set>
<ref bean="blWebTemplateResolver" />
</set>
</property>
<property name="dialects">
<set>
<ref bean="thymeleafSpringStandardDialect" />
<ref bean="blDialect" />
</set>
</property>
</bean>
If you were to have the following in your own applicationContext.xml file:
Code: Select all
<bean id="blWebTemplateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine">
<property name="dialects">
<set>
<ref bean="myDialect" />
</set>
</property>
</bean>
The actual bean that would get passed to Spring would be:
Code: Select all
<bean id="blWebTemplateEngine" class="org.thymeleaf.spring3.SpringTemplateEngine">
<property name="templateResolvers">
<set>
<ref bean="blWebTemplateResolver" />
</set>
</property>
<property name="dialects">
<set>
<ref bean="thymeleafSpringStandardDialect" />
<ref bean="blDialect" />
<ref bean="myDialect" />
</set>
</property>
</bean>
You can see which beans/properties support merging in default.properties (though it is a bit hard to understand).
I'm not entirely sure that the @Configuration annotation would handle this with as much flexibility as we provide, but to be honest, I haven't researched that particular annotation very much.
Hope that helps.