When trying to start a filter that has the @Transactional annotation on it (either org.springframework.transaction.annotation.Transactional or javax.transaction.Transactional), Tomcat fails to start up with the gradlew bootRun command. Below is the smallest amount of code where the issue is reproducible.
It was working fine with Java 11 / gradle 7.0.2.
Context Java: OpenJDK Runtime Environment (build 17+35-2724) Gradlew: 7.2
build.gradle
plugins {
id 'org.springframework.boot' version '2.5.5'
id 'io.spring.dependency-management' version '1.0.11.RELEASE'
id 'java'
}
sourceCompatibility = '17'
dependencies {
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
implementation 'org.springframework.boot:spring-boot-starter-web'
}
repositories {
mavenCentral()
}
MyApplication.java
@SpringBootApplication
public class MyApplication {
public static void main(String[] args) {
SpringApplication.run(MyApplication.class, args);
}
}
@Transactional
@Component
class TransactionalFilter extends GenericFilter {
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
chain.doFilter(request, response);
}
}
Tomcat startup logs
2021-09-28 23:50:07.665 < | > DEBUG [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Starting filters
2021-09-28 23:50:07.665 < | > DEBUG [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Starting filter 'requestContextFilter'
2021-09-28 23:50:07.667 < | > DEBUG [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Starting filter 'Tomcat WebSocket (JSR356) Filter'
2021-09-28 23:50:07.667 < | > DEBUG [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Starting filter 'transactionalFilter'
2021-09-28 23:50:07.674 < | > ERROR [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Exception starting filter [transactionalFilter]
java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "cause" is null
at org.springframework.cglib.core.CodeGenerationException.<init>(CodeGenerationException.java:25)
at org.springframework.cglib.core.ReflectUtils.defineClass(ReflectUtils.java:587)
at org.springframework.cglib.core.AbstractClassGenerator.generate(AbstractClassGenerator.java:363)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:110)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData$3.apply(AbstractClassGenerator.java:108)
at org.springframework.cglib.core.internal.LoadingCache$2.call(LoadingCache.java:54)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at org.springframework.cglib.core.internal.LoadingCache.createEntry(LoadingCache.java:61)
at org.springframework.cglib.core.internal.LoadingCache.get(LoadingCache.java:34)
at org.springframework.cglib.core.AbstractClassGenerator$ClassLoaderData.get(AbstractClassGenerator.java:134)
at org.springframework.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:319)
at org.springframework.cglib.reflect.FastClass$Generator.create(FastClass.java:65)
at org.springframework.cglib.proxy.MethodProxy.helper(MethodProxy.java:135)
at org.springframework.cglib.proxy.MethodProxy.init(MethodProxy.java:76)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:216)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:688)
at com.myapp.TransactionalFilter$$EnhancerBySpringCGLIB$$f9892285.init(<generated>)
at org.apache.catalina.core.ApplicationFilterConfig.initFilter(ApplicationFilterConfig.java:270)
at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:105)
at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:4613)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1396)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1386)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:919)
at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:263)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardService.startInternal(StandardService.java:432)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:927)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486)
at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.initialize(TomcatWebServer.java:123)
at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.<init>(TomcatWebServer.java:104)
at org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory.getTomcatWebServer(TomcatServletWebServerFactory.java:450)
at org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory.getWebServer(TomcatServletWebServerFactory.java:199)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.createWebServer(ServletWebServerApplicationContext.java:182)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.onRefresh(ServletWebServerApplicationContext.java:160)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:577)
at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:145)
at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:754)
at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:434)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:338)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1343)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:1332)
at com.myapp.MyApplication.main(MyApplication.java:20)
2021-09-28 23:50:07.674 < | > DEBUG [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Starting filter 'characterEncodingFilter'
2021-09-28 23:50:07.674 < | > DEBUG [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Starting filter 'formContentFilter'
2021-09-28 23:50:07.674 < | > ERROR [ main] org.apache.catalina.core.StandardContext : One or more Filters failed to start. Full details will be found in the appropriate container log file
2021-09-28 23:50:07.674 < | > ERROR [ main] org.apache.catalina.core.StandardContext : Context [] startup failed due to previous errors
If the @Transactional annotation is removed from the filter, the filter is created successfully.
Comment From: jhoeller
Thanks for raising this! A revision will be available in 5.3.x snapshots shortly which will hopefully avoid issues like this for good.
We defensively handle fast class generation failure for individual methods now which seems to be the main remaining culprit on JDK 17, as encountered in our reproduction efforts for this issue. This only affects specific method calls in specific proxy scenarios, e.g. toString() calls on a proxy without an interceptor involved, which we bypass or go into a fallback code path for.
Also, we consistently rethrow the last actual defineClass exception encountered now, avoiding the (rare) cause dereference failure indicated above - and providing a clearer exception to report.
Comment From: whydoievenneedthis
That was quick. Thanks.