|
From: Colin S. <col...@ex...> - 2004-04-23 13:04:49
|
I've been thinking about how you would go about assembling multiple spring-enabled components from different sources. Consider component A and component B: both ship with an internal application context definition file, which defines the beans they work with, and ideally doesn't have to be changed at all, just used as one of the definition files making up a complete appContext. But both need to use a dataSource to feed to other beans. They could define the datasource themselves, but then you would have to to modify the config (or use an externaal property file), and the same data would have to be configured in a number of places. They could also just use a common bean name like dataSource, but then you have the problem that that name may conflict with another unrelated bean. So I think if a component is realistically going to be used by a 3rd party, it needs to name its beans in its appcontext with something like package unique ids. Then all that is needed is a way to map a component specific bean id to another id. So I propose we add the concept of a standalone alias to the BeanFactory/AppContext. In the xml variants, it would be a top level <alias> element or something similar, and all it would do would provide an alias for an existing bean name. So component a for example would refer to the datasource as: com.whatever.componenta.dataSource and component b woudl use for example: com.something.componentb.dataSource Now the app using these components would use a multi-file appcontext definition where two of the files come from the respective components, and one file is for the app itself, and in that it would provide aliases so the datasource can be found. <alias from="com.whatever.componenta.dataSource" to="myDataSource"/> <alias from="com.something.componentb.dataSource" to="myDataSource"/> I think this is relatively trivial to implement, and would be pretty useful in these kinds of situations. What do you guys think? Regards, Colin |