You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The root cause is #2308. When the test that starts Tomcat (WebEnvironment.RANDOM_PORT or DEFINED_PORT) runs, the thread context class loader is set to Tomcat's web app class loader. As the context is cached, no clean up is performed after the tests are finished so the TCCL is left being Tomcat's web app class loader. This then breaks the proxy creation in a subsequent test that refreshes a new context.
We already hit another variant of the problem in #5141. We avoided it then using @DirtiesContext so that the context is closed when the tests are finished. That's not a general solution as, unlike, our integration tests where the configuration is rarely the same from test class to test class, tests for a user's application are likely to have common configuration making context caching worthwhile.
Hook into the test framework so that the TCCL is configured correctly
If it's possible, 2 is the preferred option. We'd need a hook to restore the TCCL after a test class has finished and then to reinstate it before a test class runs.
The text was updated successfully, but these errors were encountered:
I've implemented a test execution listener that manages the TCCL but it feels like a bit of a hack. I'm going to explore a third option: a different fix for #2308 so that JNDI lookups work but without us messing around with the TCCL.
https://stackoverflow.com/questions/37342590/java-lang-illegalaccesserror-when-making-spring-data-repo-package-local
The root cause is #2308. When the test that starts Tomcat (
WebEnvironment.RANDOM_PORT
orDEFINED_PORT
) runs, the thread context class loader is set to Tomcat's web app class loader. As the context is cached, no clean up is performed after the tests are finished so the TCCL is left being Tomcat's web app class loader. This then breaks the proxy creation in a subsequent test that refreshes a new context.We already hit another variant of the problem in #5141. We avoided it then using
@DirtiesContext
so that the context is closed when the tests are finished. That's not a general solution as, unlike, our integration tests where the configuration is rarely the same from test class to test class, tests for a user's application are likely to have common configuration making context caching worthwhile.I can see two possible solutions:
If it's possible, 2 is the preferred option. We'd need a hook to restore the TCCL after a test class has finished and then to reinstate it before a test class runs.
The text was updated successfully, but these errors were encountered: