Spring Java config : Specify class only

Question

I'm in the process of moving some Xml-Based spring config over to Java-based.

Previously, I've consciously mixed Xml <bean class='foo' /> declarations with @Component mappings on a case-by-case basis, as a means of documenting non-obvious beans.

A typical use case would be if I'm declaring beans that will modify the behaviour of spring itself, I'll declare these explicitly, rather than let them be discovered, purely to improve the clarity of the config file.

However, often these beans will need a degree of @Autowiring. If I new the bean up myself within a Java config, I become responsible for performing this wiring -- which is pointless.

Is there a pure Java configuration option that explicitly provides a class back to Spring, and let's it manage the instantiation?

ie:

Given the class:

public class MyFunkySpringBean implements InitializingBean {
    @Autowired Foo foo;
}

In XML config, this would be declared as simply as:

<bean class="MyFunkySpringBean" />

Is there an equivalent in Java syntax, where I can explicitly declare the bean class to Spring, but not be responsible for providing the actual instance -- leaving that to Spring.

Eg:

@Configuration 
public class MyAppConfig {

    // Explictly provide the class, not the instance to Spring
    @Bean
    public MyFunkySpringBean funkyBean; // No instance -- it's up to Spring to build
}

To be clear, I don't want to have to do this:

@Configuration 
public class MyAppConfig {

    @Bean
    public MyFunkySpringBean funkyBean() {
         MyFunkySpringBean bean = new MyFunkySpringBean();
         bean.foo = new Foo();
         // other dependencies go here
         return bean;
    }

}

Does facility like this exist within Spring?

Answer 1

I understand from your comments that you are looking for a way how to achieve constructor autowiring (with type or annotation autowiring) in Java config... i.e. equivalent of:

<bean class="com.example.Foo" autowire="constructor" />

I've checked Spring's source to find who is actually responsible for the constructor resolution and autowiring and it is a combination of package private class ConstructorResolver and AbstractAutowireCapableBeanFactory. So that is something you will not be able to use on your own.

If you really really want to have constructor autowiring without XML, you can implement your own BeanDefinitionRegistryPostProcessor and manually register that bean definitions yourself:

public class CustomBeanDefinitionRegistrar implements BeanDefinitionRegistryPostProcessor {

    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) {
        // Not interested in this method
    }

    @Override
    public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) {
        registry.registerBeanDefinition("foo", BeanDefinitionBuilder.
                genericBeanDefinition(Foo.class).
                setAutowireMode(AutowireCapableBeanFactory.AUTOWIRE_CONSTRUCTOR).
                getBeanDefinition());
    }

}

This bean factory post processor then needs to be registered via static @Bean method in your @Configuration:

@Configuration
public class MyAppConfig {

    public static BeanFactoryPostProcessor customBeanDefinitionRegistrar() {
        return new CustomBeanDefinitionRegistrar();
    }

}

I admit it is a bit "wild approach", but it seems to be the only way how to achieve constructor autowiring with pure Java config.

Answer 2

You need to notify Spring a way to discover the beans that will manage. You only have three ways (there's a fourth one but it is more complex and requires annotations as well, explained here):

• XML based configuration:

  <bean id="foo" class="some.package.Foo" />
  

• Annotation configuration:

  @Component
  public class Foo {
  }
  

• Create a @Configuration class that declares the beans explicitly:

  @Configuration
  public class MyConfiguration {
      @Bean
      public Foo getFoo() {
          return new Foo(); //foo doesn't need any annotation at all.
      }
  }
  

---

AFAIK you're able to do something similar using CDI:

class MyConfiguration {

    @Produces
    Foo foo = new Foo();
}

Or by injecting a resource from another container, like JPA:

class MyConfiguration {

    //JPA will provide the object reference based on the persistence unit
    //CDI will just work as a by-pass to inject this reference in other beans
    @PersistenceContext //JPA annotation
    @Produces
    EntityManaged em;
}

But even CDI needs a way to know how to initialize the bean or where to retrieve it first.

Refer to:

• The Java EE 7 Tutorial. 25.3 Using Producer Methods, Producer Fields, and Disposer Methods in CDI Applications
• Please explain the @Produces annotation in CDI

Answer 3

In newer versions of Spring (as of 4.2) you can use org.springframework.context.annotation.Import e.g.

@Configuration
@Import(MyFunkySpringBean.class)
public class MyAppConfig {
   ... other config ...
}

Answer 4

Does facility like this exist within Spring?

The answer is kind of, but it is not clean.

All bean definitions in Spring depend on a BeanDefinition object in the ApplicationContext.

With an XML configuration like

<bean class="com.example.SomeType">
</bean>

Spring will generate a RootBeanDefinition with that class type and as a singleton, but with no other information about how it should be constructed. Instead the ApplicationContext will determine how to create the bean.

With Java configuration like

@Bean
public com.example.SomeType someType() {
    return new com.example.SomeType();
}

Spring will create a RootBeanDefinition but specifically state that the bean should be generated from the @Configuration bean as a factory-bean and its someType() method as a factory-method. The ApplicationContext therefore doesn't have to decide for itself, it just does what the BeanDefinition tells it.

(Incomplete, I'll be back later to finish this.)

---

You have to understand that XML and Java configurations are different but try to achieve the same thing.

When you declare an XML <bean> element like so

<bean class="com.example.SomeType">
</bean>

You are telling Spring to use the parameterless constructor of SomeType to instantiate the bean class and create a bean.

In Java, the equivalent would be

@Bean
public com.example.SomeType someType() {
    return new com.example.SomeType();
}

Similarly,

<bean class="com.example.SomeType">
    <constructor-arg type="java.lang.String" value="hello world"/>
    <property name="some" value="some value" />
</bean>

is telling Spring to use a constructor with one parameter of type String with that given value to instantiate the bean class. Then set some property. The equivalent is

@Bean
public com.example.SomeType someType() {
    com.example.SomeType someType = new com.example.SomeType("hello world");
    someType.setSome("some value");
    return someType;
}

These beans will still be candidates for autowiring just like any other. If they have @Autowired fields or methods, those will be injected.

All the above configs tell Spring exactly how to create the bean. Something like this

@Bean
public MyFunkySpringBean funkyBean; // No instance -- it's up to Spring to build

doesn't really say anything unless conventions are set. I don't see any advantage to that feature that you can't get with a classic @Bean method.