-
Notifications
You must be signed in to change notification settings - Fork 38.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thread-scoped bean creation freezes if dependent bean is retrieved before dependency bean #25801
Comments
Potentially related to #25618. @nguyenquoc, out of curiosity, what version of the JDK are you using? |
I tried to reproduce this with the following all-in-one test class. @SpringJUnitConfig
@TestExecutionListeners(listeners = MyConfigTests.MyConfigTestExecutionListener.class, mergeMode = MergeMode.MERGE_WITH_DEFAULTS)
class MyConfigTests {
@Autowired
MyView myView;
@Autowired
MyPresenter myPresenter;
@Test
void testSomething() {
// empty test, never runs because Bean creation freezes
}
static class MyConfigTestExecutionListener extends AbstractTestExecutionListener {
@Override
public int getOrder() {
return Ordered.HIGHEST_PRECEDENCE;
}
@Override
public void prepareTestInstance(TestContext testContext) throws Exception {
if (testContext.getApplicationContext() instanceof GenericApplicationContext) {
GenericApplicationContext context = (GenericApplicationContext) testContext.getApplicationContext();
ConfigurableListableBeanFactory beanFactory = context.getBeanFactory();
beanFactory.registerScope("thread", new SimpleThreadScope());
}
}
}
@Configuration
static class MyConfig {
@Bean
@Scope("thread")
MyView myView(MyPresenter myPresenter) {
return new MyView(myPresenter);
}
@Bean
@Scope("thread")
MyPresenter myPresenter() {
return new MyPresenter();
}
}
static class MyView {
MyView(MyPresenter myPresenter) {
}
}
static class MyPresenter {
}
} This passes against 5.2.7, 5.2.8, 5.2.9, and master using Java 8. It fails on 5.2.7 and 5.2.8 using Java 11+, but that failure is different and was fixed in #25618. @nguyenquoc, can you please run the above test class in your environment and let me know if it passes for you? |
Using JDK: openjdk version "1.8.0_265" Reproduced on Windows and Linux also. |
Thanks for the feedback!
Were you able to reproduce it using the all-in-one test case I posted in #25801 (comment)? |
The all-in-one test case runs fine in my environment. Apologies, I haven't had a chance to create.a minimal test case to demonstrate the bug yet partially because I have a workaround. |
Thanks for confirming.
No problem. It appears that the bug may only arise in more complex scenarios which may be difficult to reproduce in a reliable test case. If you find a way to reliably reproduce the bug in the coming week, that would be great! If not, we might just roll back the changes introduced in #25038 and #25618, since this would effectively be the second reported regression for these code paths. |
I updated the original post with a standalone test case, thanks for providing the all-in-one sample. Amazingly, the name of the bean in the configuration class seems to matter. |
Thanks. And... you're welcome.
OK. That seems truly bizarre. We'll investigate! |
I figured out what's going on here. Basically, the two bean names This bug was fixed in Java 9 (see https://bugs.openjdk.java.net/browse/JDK-8062841). When I execute the same test on Java 9 or higher, the test fails with the following root cause.
Note that changing the initial capacity of the Changing the names of the two beans has a similar effect, but we cannot rely on user-defined bean names to magically work, and we cannot pick a magic initial capacity that seems to work. In light of the above findings, we do in fact consider this a regression, and we will revert the corresponding changes introduced in #25038 and #25618. p.s. for those interested... With the default initial capacity for With an initial capacity of 12 for |
Thanks very much @sbrannen, appreciate the thorough investigation! |
Affects: 5.2.9
It seems that if a dependent thread-scoped bean is retrieved from the
ApplicationContext
before the thread-scoped dependency, then bean creation could lock up in an infinite loop, never to return again.Regression bug. Works fine with spring-framework 5.2.7, fails with spring-framework 5.2.9. May be a bug in spring-test rather than spring-context. May be hard to reproduce, hoping that this limited information is sufficient to lead to a fix.
SimpleThreadScope
likely relevant sinceSimpleThreadScope
has an infinite loop - the bean creation freezes in:Standalone test case:
2 possible workarounds found:
Workaround 1: Add
@DependsOn
annotation to configuration class. However,@DependsOn
would not be necessary if there were no bug:Workaround 2: swap order of beans in test. The order of the beans would not matter if there were no bug.
The text was updated successfully, but these errors were encountered: