Colin:
To continue...
1. If the beans element had an id attribute then it would allow some new capabilities.
Thus, using the composite pattern, the beans collection itself becomes a bean, a "can of beans"
. The present way Spring works, though great, is like combing one's head one hair at a time.
A. Namespace like support. For example: ctx.getBean("utils:transformer");
B. Easier beans graph configuration.
C. Conditional configuration.
E. and more
Of course, Spring doesn't work this way or will. I'm just noting some thoughts.
2. Here is an example of what I'm talking about. This is the same example shown
in the api at http://www.springframework.org/docs/...ryLocator.html
See the last example, where multiple config files are used in a hierarchy. The source element below hides what is actually used to load the beans config.
Code:
Definitions of beans as "cans" (as in can of beans, grin).
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans ..............>
<beans id="com.mycompany.myapp.util" lazy-init="true">
<source><value>classpath:com/mycompany/myapp/util/applicationContext.xml</value></source>
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans ..............>
<beans id="com.mycompany.myapp.dataaccess" lazy-init="true" parent="com.mycompany.myapp.util">
<source><list><value>classpath:com/mycompany/myapp/dataaccess/applicationContext.xml</value></list></source>
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans ..............>
<beans id="com.mycompany.myapp.services" lazy-init="true" parent="com.mycompany.myapp.dataaccess">
<source><list><value>classpath:com/mycompany/myapp/dataaccess/services.xml</value></list></source>
</beans>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans ..............>
<beans> <!-- define an alias -->
<bean id="com.mycompany.myapp.mypackage" class="java.lang.String">
<constructor-arg><value>com.mycompany.myapp.services</value></constructor-arg>
</bean>
</beans>
--- Josef Betancourt