Thursday, February 7, 2013

Spring Bean names

Spring bean names are straightforward, except for cases where names are not explicitly specified.

To start with, Spring bean names for an xml based bean definition is specified this way:

<bean name="sampleService1" class="mvcsample.beanname.SampleService">
 <constructor-arg>
  <bean class="mvcsample.beanname.SampleDao"></bean>
 </constructor-arg>
</bean>

For a Java @Configuration based bean definition, the method name of the @Bean annotated method becomes the bean name:

@Configuration
@ComponentScan(basePackages="mvcsample.beanname")
public static class SpringConfig{
 
 @Bean
 public SampleService sampleService(){
  return new SampleService(sampleDao());
 }
 
 @Bean
 public SampleDao sampleDao(){
  return new SampleDao();
 }
 
}


and for Stereotype annotation(@Component, @Service, @Repository etc) based beans, the value field indicates the bean name:
@Repository("aSampleDao")
public class SampleDao {
    ...
}

@Service("aSampleService")
public class SampleService {
    ...
}

Now, what happens for cases where the bean name is not specified.

XML Based Bean Configuration Case:
For an xml based configuration, a case where the bean name is typically not specified are for beans which can act on the entire bean factory - say for eg, to define a BeanPostProcessor or a BeanFactoryPostProcessor
For eg. consider the following dummy BeanPostProcessor that just grabs all the bean names from bean factory:
public class BeanNameScanningBeanPostProcessor implements BeanPostProcessor{
 private List<String> beanNames = new ArrayList<>();
 @Override
 public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
  return bean;
 }

 @Override
 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
  beanNames.add(beanName);
  return bean;
 }
 
 public List<String> getBeanNames(){
  return this.beanNames;
 }
}

It would typically be defined in an xml bean configuration this way:
<bean class="mvcsample.beanname.BeanNameScanningBeanPostProcessor"/>

A second case with xml based configuration where a name is typically not specified is with inner beans, for eg. defined this way:
<bean class="mvcsample.beanname.SampleService">
 <constructor-arg>
  <bean class="mvcsample.beanname.SampleDao"></bean>
 </constructor-arg>
</bean>

The bean names for these cases is handled by a component called the BeanNameGenerator. For the case of a top level bean the name typically ends up being the package qualified class name along with a count of the instances, this way:

mvcsample.beanname.BeanNameScanningBeanPostProcessor#0

For the case of an inner bean, since it exists only in the scope of its containing bean, the name is not that relevant, however internally it does get a name based on the hex hash code of the bean definition for eg, "mvcsample.beanname.SampleDao#1881ee8b"


Java Based @Configuration Case:
For java based @Configuration on the other hand it is not possible to specify a bean without a name, the bean name is the method name.

Annotation based Configuration
For stereotype annotation based bean, if the name is not explicitly specified with the value field of stereotype annotations, then the name is again generated by AnnotationBeanNameGenerator which is an implementation of the BeanNameGenerator strategy interface, the names generated is simply the short name of the class, for eg from the javadoc for AnnotationBeanNameGenerator - bean name for com.xyz.FooServiceImpl becomes fooServiceImpl.

Conclusion:
So to finally conclude, if bean names are relevant to you in some way(for eg to disambiguate between multiple bean instances of same type), then it is best to be explicit about the names, otherwise depend on Spring to generate the bean names for you. In some cases, for eg. with Spring-data project it is possible to specify custom behavior for repositories as a separate bean and Spring-data by default uses Spring naming conventions to find the custom implementation and understanding how bean names are generated helps.


No comments:

Post a Comment

Post a Comment