Menu
▾
▴
springframework-developer
|
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 |
|
From: Tom T. <tom...@pr...> - 2004-04-24 21:47:57
|
Colin, In our project, we have some common functionality that's developed separately and included as a jar file, so I've been thinking about this as well. As the common beans are usually defined in the app's own xml file, however, you can use the regular alias functionality: <bean id="myDataSource" name="com.whatever.componenta.dataSource,com.something.componentb.dataSource" class="..."> ... </bean> The standalone alias functionality would only be needed if you wanted to make a bean of component A available with a different name to component B. I don't think that's a common scenario... Best regards, Tom. On Fri, 23 Apr 2004 09:08:05 -0400, "Colin Sampaleanu" <col...@ex...> said: > 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 > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek > For a limited time only, get FREE Ground shipping on all orders of $35 > or more. Hurry up and shop folks, this offer expires April 30th! > http://www.thinkgeek.com/freeshipping/?cpg=12297 > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-04-24 23:12:55
|
Tom, That's a decent technique, and does cover most cases. I think however a standalone alias definition would cover the remaining cases, and would also be clearer some of the time w/respect to being a very explicit 'wiring-up' of components. There's actually another way to handle this too that I can think of, and that's to add in a FactoryBean that simply returns a target bean that's passed to it as a ref. It'd be very slightly less efficient than a real alias, but I don't think it would make much of a difference in practice. Tom Turelinckx wrote: >Colin, > >In our project, we have some common functionality that's developed >separately and included as a jar file, so I've been thinking about this >as well. > >As the common beans are usually defined in the app's own xml file, >however, you can use the regular alias functionality: > ><bean id="myDataSource" >name="com.whatever.componenta.dataSource,com.something.componentb.dataSource" >class="..."> >... ></bean> > >The standalone alias functionality would only be needed if you wanted to >make a bean of component A available with a different name to component >B. I don't think that's a common scenario... > >Best regards, >Tom. > >On Fri, 23 Apr 2004 09:08:05 -0400, "Colin Sampaleanu" ><col...@ex...> said: > > >>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 >> >> |
