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.

Comment From: 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?

Comment From: ttddyy

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

Comment From: jamesmoessis

Perfect! Thanks @ttddyy

Comment From: 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.

Comment From: 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?