Announcement Announcement Module
Collapse
No announcement yet.
non-unique names with AnnotationBeanNameGenerator Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • non-unique names with AnnotationBeanNameGenerator

    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.

  • #2
    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.

    Comment


    • #3
      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
      }

      Comment

      Working...
      X