Migrating from Spring 6.1.x to 6.2.x leads to exceptions in a Pekko setup

[gmarfia88]

I am working on a Jakarta EE application that uses Spring Framework (not Spring Boot). After upgrading the spring-framework-bom version from 6.1.16 to 6.2.x, the following issues have emerged:

1. Issue with injecting generic beans. Some beans defined with generics are no longer injected correctly. For example:

   @Bean public MyInterface myBean() { return new MyClass<>(); } // raw type definition

   bean injected as follows:

   @Qualifier("myBean") @Autowired private MyClass<MyObject> myBean; // MyClass implements MyInterface

   This generates an exception stating that no bean of type MyClass exists.

2. Random errors during deployment. In some cases, the application deployment fails with the following exception: Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'exampleBean': Requested bean is currently in creation: Is there an unresolvable circular reference or an asynchronous initialization dependency?

   The issue is non-deterministic: in subsequent deployments, the exception is reported for different beans. I have verified that these issues have been reported and tracked in the official Spring Framework tickets: Migrating spring 6.1.x to 6.2.x leads to BeanCurrentlyInCreationException #34271 and BeanCurrentlyInCreationException is thrown when multiple threads simultaneously try to create bean #34186

3. Java Config injection sometimes fails. In certain cases, the injection of a Java Config class fails. For example:

   @Autowired private MyJavaConfig myJavaConfig;

   @Bean public MyBuilder myBuilder() { return new MyBuilder(this.myJavaConfig.serviceFactory()); }

   This generates the following exception: Caused by: java.lang.NullPointerException: Cannot invoke "MyJavaConfig.serviceFactory()" because "this.myJavaConfig" is null

These issues occur randomly, and I have not been able to reproduce them in a greenfield project. However, reverting to version 6.1.16 of Spring Framework resolves the deployment issues.

Has anyone encountered similar problems with Spring Framework 6.2.x, or does anyone have suggestions on how to address these cases?

[snicoll]

What version are you using. You mentioned 6.2.x but not the actual version. 1 and 2 looks duplicate of already raised concerns that are fixed in 6.2.2.

Also please do not create "meta-issue" like this. For each problem, search first in the issue tracker if an issue has already been raised.

[gmarfia88]

The latest tests were done with version 6.2.2 but I confirm the problems reported in points 2 and 3. (For point 1 I will probably have to check again on 6.2.2).

[bclozel]

2. already got an extensive comment from Juergen explaining the situation. Please apply the advice in your application.

As for 3), your configuration has been relying on an unspecified order and worked by accident. Declaring dependencies is the expected way:

@Bean 
public MyBuilder myBuilder(MayJavaConfig myJavaConfig) { return new MyBuilder(myJavaConfig.serviceFactory()); }

I'm closing this issue for now. We can reopen it if you provide a sample application that uses Spring Framework 6.2.2 and reproduces the problem.

[gmarfia88]

Hi,
I am commenting on the ticket because the issue with circular dependencies occurs in a single-threaded context. I do not have any custom configurations for multi-threading, and, as far as I know, Spring by default does not use multiple threads for context initialization. Could you please confirm if this statement is correct?

Regarding point 3, I would like to emphasize that my application has been working correctly for years with the current configuration. The suggestion you proposed would force me to modify thousands of configurations due to a minor update (from 6.1.16 to 6.2.x) of Spring Framework.

Moreover, by injecting a Java Config via @Autowired, I can define a bean without needing to pass a parameter as input, as shown in the following example:

public interface ConfigInterface { MyBuilder myBuilder(); }

@Configuration public class ConfigA implements ConfigInterface {

@Autowired private MyJavaConfig myJavaConfig;

@Bean @Override public MyBuilder myBuilder() { return new MyBuilder(this.myJavaConfig.serviceFactory()); }
}

@Configuration
public class ConfigB {

@Autowired private ConfigInterface configInterface;

@Bean public MyBean myBean() { return new MyBean(this.configInterface.myBuilder()); }

}

If I were to follow your suggestion and add the configuration as a bean parameter, I would also need to inject MyJavaConfig, which would further complicate the management:

@Configuration public class ConfigA implements ConfigInterface {

@Bean @Override public MyBuilder myBuilder(MyJavaConfig myJavaConfig) {
return new MyBuilder(myJavaConfig.serviceFactory());
}
}

@Configuration public class ConfigB {

@Bean public MyBean myBean(ConfigInterface configInterface, MyJavaConfig myJavaConfig) {
return new MyBean(configInterface.myBuilder(myJavaConfig));
}
}

This approach could result in a less clean design, as I might not want to expose MyJavaConfig to ConfigB.

[bclozel]

I am commenting on the ticket because the issue with circular dependencies occurs in a single-threaded context. I do not have any custom configurations for multi-threading, and, as far as I know, Spring by default does not use multiple threads for context initialization. Could you please confirm if this statement is correct?

This is correct, Spring Framework does not use multiple threads by default for context initialization. You can confirm whether this is the case in your application by applying the advice from this comment: #34308 (comment)

Regarding point 3, I would like to emphasize that my application has been working correctly for years with the current configuration. The suggestion you proposed would force me to modify thousands of configurations due to a minor update (from 6.1.16 to 6.2.x) of Spring Framework.

Apologies, I didn't realize that your MyJavaConfig was an actual @Configuration class. I think that autowiring a configuration class into another is a major design issue in the first place. As you've pointed out, this has been working for a long time anyway so we'll be waiting for your analysis on the probable multi-threaded initialization.

[jhoeller]

@gmarfia88 to be clear, if you encounter an unexpected BeanCurrentlyInCreationException during single-threaded startup just going from 6.1.x to 6.2.x, that would qualify as a bug that we would definitely like to have a reproducer for. That said, since it is non-deterministic, it is highly likely that there is another thread involved during startup; we would like to learn about where that is being started so that we can fine-tune the locking algorithm for 6.2.3 if possible.

The config class injection failure may be a consequence of circular reference resolution. So this may possibly be connected to the problem above, with the container trying to resolve a BeanCurrentlyInCreationException through a fallback and failing there. I would not worry about that part too much at this point, there is no need to revisit your config classes. Let's try to track down the BeanCurrentlyInCreationException scenario first and then see whether a remaining problem persists for config classes specifically.

Your type matching problem is tied to a different area of fine-tuning. We've fixed several generic type matching regressions in 6.2.2 already and are about to address one more in 6.2.3. A reproducer against 6.2.2 would be very much appreciated there, ideally attached to a new issue for that specific problem.

[gmarfia88]

Hi @jhoeller,
I have probably identified a part of my application that uses a thread pool to instantiate some beans. As a result (although I am not yet completely sure), the context loading might be happening in a multi-threaded manner.

I agree that we should not worry for now about the issue regarding configuration injection and generics, but instead focus on understanding and resolving the BeanCurrentlyInCreationException. Unfortunately, I need some time to figure out how to postpone the initialization of those beans or, in general, how to bypass the issue to verify that, once this is fixed, everything works correctly again.

As soon as possible, I will try to detail the bean creation logic in my scenario so that you can evaluate possible improvements for the next version.

Thanks a lot!