Support for fine-grained by-type references in the bean definition model

[jxblum]

After reviewing the core Spring Framework BeanReference implementations, I got to thinking if there was a RuntimeBeanTypeReference like implementation, or something similar?

I am aware of the RuntimeBeanReference and RuntimeBeanNameReference implementations, however, both of these only refer to a “single” bean in the Spring context.

This is useful in situations like the following.

Given:

class A {
    B b;
    // getters/setters omitted
}

class B { 
    ... 
}

Then in a framework (e.g. Spring Data or Spring Session, etc) provided ImportBeanDefinitionRegistrar implementation, I can:

class CustomImportBeanDefinitionRegistrar implements ImportBeanDefinitionRegistrar {

    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {

        BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition(A.class);

        builder.addPropertyReference("b",  "nameOfSingleBeanB");

        // Or alternatively...
        builder.addPropertyValue("b", new RuntimeBeanReference("nameOfSingleBeanB"));

        registry.registerBeanDefinition.register("nameForBeanA", builder.build());
    }
}

However, what if I want to register a BeanDefinition who’s class type has a property that requests all beans of a particular type declared and registered in the Spring container?

Reimagining our class definitions from above:

class A {
    B[] b
    // getters/setters omitted
}

class B {
    ...
}

Then, with a RuntimeBeanTypeReference, I could:

class CustomImportBeanDefinitionRegistrar implement ImportBeanDefinitionRegistrar {

    public void registerBeanDefinitions(AnnotationMetadata importingClassMetadata, BeanDefinitionRegistry registry) {

        BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition(A.class);

        builder.addPropertyReference("b",  new RuntimeBeanTypeReference(B.class));

        registry.registerBeanDefinition("nameForBeanA", builder.build());
    }
}

I know we also have things like Managed[List|Map|Set] which can take 1 or more BeanReference objects, but again, I am constrained by having to know all the bean names possibly registered in the container upfront.

Of course, I could iterate the BeanFactory, beanDefinitionNames and inspect each BeanDefinition to determine if the class of the bean definition matches my desired type (e.g. B).

But, this does not work so well with @Configuration classes as it turns out.

It seems that when looking at the beanDefinitionMap the @Configuration classes have not be resolved with any @Bean definitions they contain, particularly when inspecting the BeanFactory (e.g. getBeansOfType(..)) inside a ImportBeanDefinitionRegistrar.

Therefore, by iterating (prematurely), I would not know if those @Configuration classes (or really, any @Component class), which is allowed to contain other @Bean definitions, would potentially match beans of my desired type (i.e. B).

Hence the thinking behind a RuntimeBeanTypeReference implementation.

I suppose class A could be defined as:

class A {
    @Autowired
    B[] b;
}

But, if annotation config (autowiring) were not enabled (which even though maybe uncommon), would not work.

Hence my thinking behind a RuntimeBeanTypeReference implementation.

Thoughts?

[jxblum]

Actually, thinking about this further, the RuntimeBeanTypeReference would even work for a single collaborator/dependency reference, as in the original class A definition, as follows:

class A {
    B b;
    // getter/setters omitted
}

The BeanDefinition could still be as follows:

BeanDefinitionBuilder builder = BeanDefinitionBuilder.genericBeanDefinition(A.class);

build.setPropertyValue("b", new RuntimeBeanTypeReference(B.class));

registry.registerBeanDefinition("beanNameForA", builder.build());

Of course, the Spring container would expect only a single bean of type B to be declared and registered in the configuration, otherwise a NoUniqueBeanDefinitionException would be thrown.

Alternately, it might be a nice addition to this feature if the collaborator/dependency could still be resolved, even with multiple beans of type B declared and registered in the Spring container if the desired collaborator was qualified, something like:

class A {

  @Qualifier("QualifiedB")
  B b;
}

Or...

class A {

  B b;

   @Qualifier("QualifiedB")
    public void setB(B b) {
        this.b = b;
    }
}

Or if one of the multiple B type bean instances was marked as the @Primary:

@Configuration
class ApplicationConfiguration {

    @Bean
    @Primary
    B primaryB() {
        return new B();
    }

    @Bean
    B anotherB() {
        return new B();
    }
}

Then, the Spring container would still do the right thing and resolve the correct B bean instance.

Food for thought.

[jhoeller]

I've introduced overloaded constructors on RuntimeBeanReference that point to a bean by Class, adapting straight to getBean(Class) analogous to getBean(String). This may be useful for specific purposes, e.g. resolution of an interface-typed dependency to a specific implementation class bean.

For general autowiring purposes, covering individual bean types but also collection types and arrays (following our common dependency resolution rules for autowired injection points), I've introduced an AutowiredPropertyMarker that can be added to the PropertyValues for a specific property of a specific bean, triggering autowired resolution through the resolveDependency algorithm just like an @Autowired annotation or an AUTOWIRE_BY_TYPE setting would. For convenience and discoverability, I've also added an addAutowiredProperty method to BeanDefinitionBuilder.

To be committed soon :-)