Re: [Springframework-developer] Standalone alias definitions in the BeanFactory/ApplicationContext

[Colin S. <col...@ex...>]

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
>>    
>>