CGLIB proxy classes are no longer cached properly #31238
Comments
spring-projects-issues
added
the
status: waiting-for-triage
danthe1st
changed the title
sbrannen
changed the title
@Transactional and @DirtiesContext
|
Hi @danthe1st, Thanks for raising the issue. Before we investigate this, I would appreciate it if you could answer the following questions.
|
sbrannen
added
status: waiting-for-feedback
|
spring-projects-issues
added
status: feedback-provided
|
Thanks for trying that out and providing feedback, @danthe1st! That's very helpful to know and made me think... It's likely not directly related to Based on that hunch, I have been able to reproduce this bug in a stand-alone integration test without GraalVM involved. package org.springframework.test;
// imports ...
@SpringJUnitConfig
@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD)
class TransactionalComponentTests {
static Set<String> proxyClasses = new HashSet<>();
@Autowired
MyComponent component;
@BeforeEach
void trackProxyClass() {
proxyClasses.add(component.getClass().getName());
}
@Test
void test1() {
}
@Test
void test2() {
}
@AfterAll
static void checkProxiesCreated() {
assertThat(proxyClasses)
.singleElement()
.isEqualTo("org.springframework.test.TransactionalComponentTests$MyComponent$$SpringCGLIB$$0");
}
@Configuration
@Import(MyComponent.class)
@EnableTransactionManagement
static class Config {
@Bean
DataSourceTransactionManager transactionManager(DataSource dataSource) {
return new DataSourceTransactionManager(dataSource);
}
@Bean
DataSource dataSource() {
return new EmbeddedDatabaseBuilder().generateUniqueName(true).build();
}
}
@Component
static class MyComponent {
@Transactional
void doWork() {
}
}
}
That should make it easier for us to debug the issue in the coming days. |
Out of curiosity, I performed some manual debugging to hone in on the underlying problem. Adding a print statement to From that, we can see that 3 CGLIB proxy classes are generated for We actually see that 3 CGLIB proxy classes are generated for |
sbrannen
added
type: regression
sbrannen
added
the
in: core
sbrannen
changed the title
@Transactional and @DirtiesContextApplicationContexts
sbrannen
changed the title
ApplicationContexts
sbrannen
changed the title
This commit expands the scope of equality checks in the implementation of equals() for PerTargetInstantiationModelPointcut to include all fields instead of just the pointcut expression for the declared pointcut. See spring-projectsgh-31238
For equivalence, we only need to compare the preInstantiationPointcut fields since they include the declaredPointcut fields. In addition, we should not compare the aspectInstanceFactory fields since LazySingletonAspectInstanceFactoryDecorator does not implement equals(). See gh-31238
Affects:
<spring-framework.version>6.0.12</spring-framework.version>When a Spring project using
@Transactionaland@DirtiesContextis running tests in native mode, it fails with an error like this:Steps to reproduce:
@Componentwith a@Transactionalmethod.@SpringBootTestwith a test method annotated with@DirtiesContextmvn test -PnativeTestThis results in an error like the following when running the tests:
Reproducer: https://github.com/danthe1st/spring-dirty-cglib
failed run: https://github.com/danthe1st/spring-dirty-cglib/actions/runs/6190254596/job/16806115554
build log as file: 1_build.txt
native-image version:
This issue might be related to #30939 but it occurs in a different Spring version and seems to be caused by different things.
The text was updated successfully, but these errors were encountered: