Fail fast if a @Bean method has a void return type

[snicoll]

It is currently possible to craft the following faulty configuration:

@Configuration
public class FaultyConfiguration {

	@Bean
	public void faultyBean() {
		System.out.println("Hello");
	}

}

As a result of processing this configuration class, "Hello" is displayed during the processing phase and a NullBean bean is contributed. We should reject this upfront.

[jamesmoessis]

Hi @snicoll - In 6.1.0 this is causing a problem for us. I was using void beans to run setup methods, pairing them with the @Conditional* annotations. For example, enabling certain reactor hooks, if reactor is on the class path:

    @Configuration
    @ConditionalOnClass(Mono.class)
    static class ReactiveConfiguration {
        @Bean
        void enableAutomaticContextPropagation() {
            Hooks.enableAutomaticContextPropagation();
        }
    }

I couldn't see any other way to do this, since @PostConstruct doesn't work with the annotations I need. Is there an alternative now that 6.1.0 blocks this behaviour?

[ttddyy]

@jamesmoessis fyi, see this ReactorAutoConfiguration class in Spring Boot.

[jamesmoessis]

Perfect! Thanks @ttddyy

[snicoll]

Thanks @ttddyy. @jamesmoessis I don't see really how that change blocks anything considering it was abusing @Bean factory method. The reference guide has a number of alternatives for bean initialization. Remember that a @Configuration class is also a bean so it could have implemented InitializingBean if @PostConstruct does not work for you. However, the constructor-based approach is better as it is invoked early.

[GeneralNitin]

Thanks @ttddyy. @jamesmoessis I don't see really how that change blocks anything considering it was abusing @Bean factory method. The reference guide has a number of alternatives for bean initialization. Remember that a @Configuration class is also a bean so it could have implemented InitializingBean if @PostConstruct does not work for you. However, the constructor-based approach is better as it is invoked early.

Can you please attach an example.
In my case, I was doing something like this, and after upgrading to Spring 3.2, my build started failing.

    @Bean
    @DependsOn(value = { "bean1" })
    public void initSystemProperty() {
        System.setProperty("someProperty", someValue);
    }

    @Bean
    @DependsOn(value = { "initSystemProperty" })
    public void performAnotherAction() {
        // due some more action
    }

Can you please suggest how I should refactor this?