non-unique names with AnnotationBeanNameGenerator

[memelet]

Why does AnnotationBeanNameGenerator use getClass.getSimpleName where in the xml if an id is omitted getClass.getName is used?

This is causing me much grief, as components are overriding beans where multiples of the same type are desired.

I know that I can specify a name-generator to component-scan, but that requires plugin modules (by developers possibly in other organizations) to "know" to do this for specific types. If they forget it can cause other plugins to faile -- not very api friendly.

[Marten Deinum]

Because when specifing no id in xml it is assumed this bean is going to be used nowhere and the name doesn't really matter. When using annotations and component-scanning it is assumed that the beans are used (and can be used in both xml/java/annotations) and need to have a meaningful (consistent) name.

[memelet]

Truly no no disrespect Marten, but that argument seems pretty weak to me. Xml beans and annotation beans seem fully symmetric in capabilities. Xml beans can be used in annotations just as annotation beans can be used in xml. If the name is important the @Bean annotation provides for optionally specifying a name, just as the 'id' attribute does for xml.

In any case when auto-wiring by type, names may never be used. Yet it is typical (at least in my apps) to use autowire like:

@Autowired var plugins: Array[SomeClassOfPlugin] = _

But even with the below only one bean will remain in the context.

@Configuration
class MyConfig1 {
@Bean p1 = new SomeClassOfPlugin
}
@Configuration
class MyConfig2 {
@Bean p2 = new SomeClassOfPlugin
}