Re: PostConstruct annotation in a filter since version 9.0.60
Mark, I understand that no matter what the point of view is, there are requirements as to what an application can package in order to correctly run within Tomcat. I appreciate the details and thank you for elaborating on it. On Wed, Apr 6, 2022 at 2:35 AM Mark Thomas wrote: > Your application must not package any of the specification API jars > provided by Tomcat. That includes annotation-api.jar > > Tomcat implements the specific version of the API defined by those jars. > You can't drop in a different API version and expect Tomcat to magically > implement that new version of the API. > > Further, having multiple copies of the same class provided by both Tomcat > and the web application often leads to problems. > > The Java EE / Jakarta EE APIs are design with backwards compatibility in > mind. As long as you avoid deprecated methods, applications written to an > earlier version of the API will have no problems running on a Tomcat > version that supports a newer version of the API. Tomcat will even handle > the Java EE / Jakarta EE package renaming for you. > > Within the constraints above, applications are free to package any other > libraries as the see fit. > > Mark > > > 6 Apr 2022 01:23:01 Cherio : > > > This makes no sense. > > > > The application and the container need to be able to maintain an > > independent life cycle of the libraries. I may want to update Tomcat > > and > > not be concerned that it breaks my application because I may not even > > have > > means to adapt the application to the updated tomcat library versions. > > An > > application needs to be able to bring its own libraries. > > > > Unless I misunderstood the meaning of what you said you sir are > > completely > > wrong on this > > > > On Tue, Apr 5, 2022 at 5:37 PM Mark Thomas wrote: > > > >> > >> 5 Apr 2022 20:58:26 Cherio : > >> > >>> I found what the issue is. This has to do with the sequence of > >>> loading > >>> of > >>> libraries/jars AND project supplied "annotation-api.jar" which > >>> declares > >>> PostConstruct annotation. The same set of annotations are also being > >>> supplied by Tomcat in an identically named JAR. Sometime during > >>> java/Tomcat > >>> startup these libraries are being loaded in a different order > >>> depending > >>> on > >>> the tomcat version. The order is reliably different and reproducible. > >> > >> Kudos for tracking this down. > >> > >>> The conclusion is that Tomcat indeed implements Filter lifecycle > >>> annotation > >>> processing but it does not run when those annotations are loaded from > >>> the > >>> application supplied JAR. > >>> > >>> What's the recommendation on this? > >> > >> Fix the application. > >> > >> It should not be packaging classes that are provided by the container. > >> > >> That said, to protect against these sorts of app issues, Tomcat should > >> be > >> blocking the attempt to load them. I need to check why that isn"t > >> happening. > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: PostConstruct annotation in a filter since version 9.0.60
Your application must not package any of the specification API jars provided by Tomcat. That includes annotation-api.jar Tomcat implements the specific version of the API defined by those jars. You can't drop in a different API version and expect Tomcat to magically implement that new version of the API. Further, having multiple copies of the same class provided by both Tomcat and the web application often leads to problems. The Java EE / Jakarta EE APIs are design with backwards compatibility in mind. As long as you avoid deprecated methods, applications written to an earlier version of the API will have no problems running on a Tomcat version that supports a newer version of the API. Tomcat will even handle the Java EE / Jakarta EE package renaming for you. Within the constraints above, applications are free to package any other libraries as the see fit. Mark 6 Apr 2022 01:23:01 Cherio : This makes no sense. The application and the container need to be able to maintain an independent life cycle of the libraries. I may want to update Tomcat and not be concerned that it breaks my application because I may not even have means to adapt the application to the updated tomcat library versions. An application needs to be able to bring its own libraries. Unless I misunderstood the meaning of what you said you sir are completely wrong on this On Tue, Apr 5, 2022 at 5:37 PM Mark Thomas wrote: 5 Apr 2022 20:58:26 Cherio : I found what the issue is. This has to do with the sequence of loading of libraries/jars AND project supplied "annotation-api.jar" which declares PostConstruct annotation. The same set of annotations are also being supplied by Tomcat in an identically named JAR. Sometime during java/Tomcat startup these libraries are being loaded in a different order depending on the tomcat version. The order is reliably different and reproducible. Kudos for tracking this down. The conclusion is that Tomcat indeed implements Filter lifecycle annotation processing but it does not run when those annotations are loaded from the application supplied JAR. What's the recommendation on this? Fix the application. It should not be packaging classes that are provided by the container. That said, to protect against these sorts of app issues, Tomcat should be blocking the attempt to load them. I need to check why that isn"t happening. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PostConstruct annotation in a filter since version 9.0.60
This makes no sense. The application and the container need to be able to maintain an independent life cycle of the libraries. I may want to update Tomcat and not be concerned that it breaks my application because I may not even have means to adapt the application to the updated tomcat library versions. An application needs to be able to bring its own libraries. Unless I misunderstood the meaning of what you said you sir are completely wrong on this On Tue, Apr 5, 2022 at 5:37 PM Mark Thomas wrote: > > 5 Apr 2022 20:58:26 Cherio : > > > I found what the issue is. This has to do with the sequence of loading > > of > > libraries/jars AND project supplied "annotation-api.jar" which declares > > PostConstruct annotation. The same set of annotations are also being > > supplied by Tomcat in an identically named JAR. Sometime during > > java/Tomcat > > startup these libraries are being loaded in a different order depending > > on > > the tomcat version. The order is reliably different and reproducible. > > Kudos for tracking this down. > > > The conclusion is that Tomcat indeed implements Filter lifecycle > > annotation > > processing but it does not run when those annotations are loaded from > > the > > application supplied JAR. > > > > What's the recommendation on this? > > Fix the application. > > It should not be packaging classes that are provided by the container. > > That said, to protect against these sorts of app issues, Tomcat should be > blocking the attempt to load them. I need to check why that isn"t > happening. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: PostConstruct annotation in a filter since version 9.0.60
5 Apr 2022 20:58:26 Cherio : I found what the issue is. This has to do with the sequence of loading of libraries/jars AND project supplied "annotation-api.jar" which declares PostConstruct annotation. The same set of annotations are also being supplied by Tomcat in an identically named JAR. Sometime during java/Tomcat startup these libraries are being loaded in a different order depending on the tomcat version. The order is reliably different and reproducible. Kudos for tracking this down. The conclusion is that Tomcat indeed implements Filter lifecycle annotation processing but it does not run when those annotations are loaded from the application supplied JAR. What's the recommendation on this? Fix the application. It should not be packaging classes that are provided by the container. That said, to protect against these sorts of app issues, Tomcat should be blocking the attempt to load them. I need to check why that isn"t happening. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: PostConstruct annotation in a filter since version 9.0.60
> -Ursprüngliche Nachricht- > Von: Cherio > Gesendet: Dienstag, 5. April 2022 17:17 > An: Tomcat Users List > Betreff: Re: PostConstruct annotation in a filter since version 9.0.60 > > I did ran the diffs between versions. With my naked eye I didn't spot > anything obvious that in my mind would be directly related to this behavior > change. > > At the same time, when I toggle between the above mentioned Tomcat > versions the exact same application either starts successfully or fails on > PostConstruct. > > I am not stating this is a bug. It may or may not be one. Maybe it IS supposed > to process PostConstruct on filters (and maybe even other classes and > objects??) I can't classify it as a regression or a fix because I can't find > a clear > description of how this should behave. > > On Tue, Apr 5, 2022 at 10:42 AM Rémy Maucherat > wrote: > > > On Tue, Apr 5, 2022 at 4:02 PM Cherio wrote: > > > > > > Yes, I confirm. For this project I download Tomcat from here: > > > > > https://archive.apache.org/dist/tomcat/tomcat- > $MAJOR_VER/v$VER/bin/apa > > che-tomcat-$VER.tar.gz > > > > > > BTW @PostConstruct doesn't have to do with dependency injection. It > > > is about lifecycle processing. > > > > > > The change in behavior was narrowed down to switching versions from > > 9.0.59 > > > to 9.0.60. > > > > Thanks to the effort to isolate the problem, but this is not likely: > > https://github.com/apache/tomcat/compare/9.0.59...9.0.60 > > No relevant changes, so Tomcat's annotation scanning behavior won't > change. > > > > The DefaultInstanceManager is used, it seems it wasn't used before > > then. Since you're using Spring, maybe the problem could come from > > there ? > > > > > > > > The code that adds the filter is super simple: > > > > > > FilterRegistration.Dynamic filterName = > > > servletContext.addFilter(FILTER_NAME, filterObject); > > > > > > sessionContextFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherTyp > > e.REQUEST), > > > true, "/*"); > > > > > > The filter is a Spring an annotated class. in version 9.0.59 and > > > before @PostConstruct was only handled by Spring. Starting with > > > version 9.0.60, Tomcat attempts to handle PostConstruct. It produces > > > an exception (see below) and fails to start the application. > > > > > > 12:34:56.789 ERROR o.a.c.c.C.[.[.[/project-name] - Exception > > > starting filter [filterName] > > > java.lang.IllegalArgumentException: Invalid > > javax.annotation.PostConstruct > > > > Is the error message accurate (= is the annotation target funny ?). I > > understand that this is supposedly not Tomcat that should process the > > annotation (if you say so), but PostConstruct is from EE so there's > > likely a problem. Maybe it "used to work" but maybe that's a good hint > > too. > > > > Rémy > > > > > annotation > > > at > > > > > org.apache.catalina.core.DefaultInstanceManager.findLifecycleCallback( > > DefaultInstanceManager.java:719) > > > at > > > > > org.apache.catalina.core.DefaultInstanceManager.findPostConstruct(Defa > > ultInstanceManager.java:693) > > > at > > > > > > org.apache.catalina.core.DefaultInstanceManager.populateAnnotationsCac > > he(DefaultInstanceManager.java:370) > > > at > > > > > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultIns > > tanceManager.java:172) > > > at > > > > > org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultIns > > tanceManager.java:165) > > > at > > > > > org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFil > > terConfig.java:105) > > > at > > > > > org.apache.catalina.core.StandardContext.filterStart(StandardContext.j > > ava: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.j > > ava:1396) > > > at > > > > > org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.j > > ava:1386) > > > at > > > java.base/java
Re: PostConstruct annotation in a filter since version 9.0.60
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.Catalina.start(Catalina.java:772) >> > at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> > Method) >> > at >> > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) >> > at >> > >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> > at java.base/java.lang.reflect.Method.invoke(Method.java:568) >> > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) >> > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) >> > >> > >> > On Sun, Apr 3, 2022 at 9:54 AM Peter Rader wrote: >> > >> > > PostConstruct is for dependency-injection. A vanilla tomcat does no >> > > dependency injection. Can you confirm you have a vanilla tomcat? >> > > >> > > Kind regards >> > > >> > > Peter Rader >> > > -- >> > > Fachinformatiker AE / IT Software Developer >> > > Peter Rader >> > > Wilsnacker Strasse 17 >> > > 10559 Berlin - GERMANY >> > > Tel: 0049 (0)30 / 6 29 33 29 6 >> > > Fax: 0049 (0)30 / 6 29 33 29 6 >> > > Handy: 0049 (0)176 / 87 521 576 >> > > Handy: 0049 (0)176 / 47 876 303 >> > > >> > > >> > > >> > > Gesendet: Freitag, 01. April 2022 um 23:02 Uhr >> > > Von: "Cherio" >> > > An: users@tomcat.apache.org >> > > Betreff: PostConstruct annotation in a filter since version 9.0.60 >> > > I observed an announced change in behavior in version 9.0.60 (and >> later). >> > > >> > > My application has a Spring class loaded as a javax.servlet.Filter. >> It has >> > > a method annotated with a PostConstruct annotation. Up until Tomcat >> 9.0.59 >> > > the annotation was handled by Spring. Starting with Tomcat 9.0.60 >> behavior >> > > changed. Now Tomcat attempts to take action on that method. The >> attempt >> > > fails with "java.lang.IllegalArgumentException: Invalid >> > > javax.annotation.PostConstruct annotation" exception and that results >> in >> > > the whole application failing to start. >> > > >> > > I use PostConstruct in other Spring modules but it looks like Tomcat >> cares >> > > only about classes it deals with directly. >> > > >> > > I do not see this change documented anywhere so I assume this may be a >> > > regression or an undocumented bug fix or feature. >> > > >> > > Does anyone have more information about this? >> > > Thanks! >> > > >> > > - >> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> > > For additional commands, e-mail: users-h...@tomcat.apache.org >> > > >> > > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: PostConstruct annotation in a filter since version 9.0.60
> > > 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.Catalina.start(Catalina.java:772) > > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > at > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) > > at > > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:568) > > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) > > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) > > > > > > On Sun, Apr 3, 2022 at 9:54 AM Peter Rader wrote: > > > > > PostConstruct is for dependency-injection. A vanilla tomcat does no > > > dependency injection. Can you confirm you have a vanilla tomcat? > > > > > > Kind regards > > > > > > Peter Rader > > > -- > > > Fachinformatiker AE / IT Software Developer > > > Peter Rader > > > Wilsnacker Strasse 17 > > > 10559 Berlin - GERMANY > > > Tel: 0049 (0)30 / 6 29 33 29 6 > > > Fax: 0049 (0)30 / 6 29 33 29 6 > > > Handy: 0049 (0)176 / 87 521 576 > > > Handy: 0049 (0)176 / 47 876 303 > > > > > > > > > > > > Gesendet: Freitag, 01. April 2022 um 23:02 Uhr > > > Von: "Cherio" > > > An: users@tomcat.apache.org > > > Betreff: PostConstruct annotation in a filter since version 9.0.60 > > > I observed an announced change in behavior in version 9.0.60 (and > later). > > > > > > My application has a Spring class loaded as a javax.servlet.Filter. It > has > > > a method annotated with a PostConstruct annotation. Up until Tomcat > 9.0.59 > > > the annotation was handled by Spring. Starting with Tomcat 9.0.60 > behavior > > > changed. Now Tomcat attempts to take action on that method. The attempt > > > fails with "java.lang.IllegalArgumentException: Invalid > > > javax.annotation.PostConstruct annotation" exception and that results > in > > > the whole application failing to start. > > > > > > I use PostConstruct in other Spring modules but it looks like Tomcat > cares > > > only about classes it deals with directly. > > > > > > I do not see this change documented anywhere so I assume this may be a > > > regression or an undocumented bug fix or feature. > > > > > > Does anyone have more information about this? > > > Thanks! > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: PostConstruct annotation in a filter since version 9.0.60
gt; at java.base/java.lang.reflect.Method.invoke(Method.java:568) > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) > > > On Sun, Apr 3, 2022 at 9:54 AM Peter Rader wrote: > > > PostConstruct is for dependency-injection. A vanilla tomcat does no > > dependency injection. Can you confirm you have a vanilla tomcat? > > > > Kind regards > > > > Peter Rader > > -- > > Fachinformatiker AE / IT Software Developer > > Peter Rader > > Wilsnacker Strasse 17 > > 10559 Berlin - GERMANY > > Tel: 0049 (0)30 / 6 29 33 29 6 > > Fax: 0049 (0)30 / 6 29 33 29 6 > > Handy: 0049 (0)176 / 87 521 576 > > Handy: 0049 (0)176 / 47 876 303 > > > > > > > > Gesendet: Freitag, 01. April 2022 um 23:02 Uhr > > Von: "Cherio" > > An: users@tomcat.apache.org > > Betreff: PostConstruct annotation in a filter since version 9.0.60 > > I observed an announced change in behavior in version 9.0.60 (and later). > > > > My application has a Spring class loaded as a javax.servlet.Filter. It has > > a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59 > > the annotation was handled by Spring. Starting with Tomcat 9.0.60 behavior > > changed. Now Tomcat attempts to take action on that method. The attempt > > fails with "java.lang.IllegalArgumentException: Invalid > > javax.annotation.PostConstruct annotation" exception and that results in > > the whole application failing to start. > > > > I use PostConstruct in other Spring modules but it looks like Tomcat cares > > only about classes it deals with directly. > > > > I do not see this change documented anywhere so I assume this may be a > > regression or an undocumented bug fix or feature. > > > > Does anyone have more information about this? > > Thanks! > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: PostConstruct annotation in a filter since version 9.0.60
achinformatiker AE / IT Software Developer >> Peter Rader >> Wilsnacker Strasse 17 >> 10559 Berlin - GERMANY >> Tel: 0049 (0)30 / 6 29 33 29 6 >> Fax: 0049 (0)30 / 6 29 33 29 6 >> Handy: 0049 (0)176 / 87 521 576 >> Handy: 0049 (0)176 / 47 876 303 >> >> >> >> Gesendet: Freitag, 01. April 2022 um 23:02 Uhr >> Von: "Cherio" >> An: users@tomcat.apache.org >> Betreff: PostConstruct annotation in a filter since version 9.0.60 >> I observed an announced change in behavior in version 9.0.60 (and later). >> >> My application has a Spring class loaded as a javax.servlet.Filter. It has >> a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59 >> the annotation was handled by Spring. Starting with Tomcat 9.0.60 behavior >> changed. Now Tomcat attempts to take action on that method. The attempt >> fails with "java.lang.IllegalArgumentException: Invalid >> javax.annotation.PostConstruct annotation" exception and that results in >> the whole application failing to start. >> >> I use PostConstruct in other Spring modules but it looks like Tomcat cares >> only about classes it deals with directly. >> >> I do not see this change documented anywhere so I assume this may be a >> regression or an undocumented bug fix or feature. >> >> Does anyone have more information about this? >> Thanks! >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >>
Re: PostConstruct annotation in a filter since version 9.0.60
Yes, I confirm. For this project I download Tomcat from here: https://archive.apache.org/dist/tomcat/tomcat-$MAJOR_VER/v$VER/bin/apache-tomcat-$VER.tar.gz BTW @PostConstruct doesn't have to do with dependency injection. It is about lifecycle processing. The change in behavior was narrowed down to switching versions from 9.0.59 to 9.0.60. The code that adds the filter is super simple: FilterRegistration.Dynamic filterName = servletContext.addFilter(FILTER_NAME, filterObject); sessionContextFilter.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), true, "/*"); The filter is a Spring an annotated class. in version 9.0.59 and before @PostConstruct was only handled by Spring. Starting with version 9.0.60, Tomcat attempts to handle PostConstruct. It produces an exception (see below) and fails to start the application. 12:34:56.789 ERROR o.a.c.c.C.[.[.[/project-name] - Exception starting filter [filterName] java.lang.IllegalArgumentException: Invalid javax.annotation.PostConstruct annotation at org.apache.catalina.core.DefaultInstanceManager.findLifecycleCallback(DefaultInstanceManager.java:719) at org.apache.catalina.core.DefaultInstanceManager.findPostConstruct(DefaultInstanceManager.java:693) at org.apache.catalina.core.DefaultInstanceManager.populateAnnotationsCache(DefaultInstanceManager.java:370) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:172) at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:165) at org.apache.catalina.core.ApplicationFilterConfig.(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.Catalina.start(Catalina.java:772) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) On Sun, Apr 3, 2022 at 9:54 AM Peter Rader wrote: > PostConstruct is for dependency-injection. A vanilla tomcat does no > dependency injection. Can you confirm you have a vanilla tomcat? > > Kind regards > > Peter Rader > -- > Fachinformatiker AE / IT Software Developer > Peter Rader > Wilsnacker Strasse 17 > 10559 Berlin - GERMANY > Tel: 0049 (0)30 / 6 29 33 29 6 > Fax: 0049 (0)30 / 6 29 33 29 6 > Handy: 0049 (0)176 / 87 521 576 > Handy: 0049 (0)176 / 47 876 303 > > > > Gesendet: Freitag, 01. April 2022 um 23:02 Uhr > Von: "Cherio" > An: users@tomcat.apache.org > Betreff: PostConstruct annotation in a filter since version 9.0.60 > I observed an announced change in behavior in version 9.0.60 (and later). > > My application has a Spring class loaded as a javax.servlet.Filter. It has > a method annotated with a PostConstruct annotation. Up unt
Re: PostConstruct annotation in a filter since version 9.0.60
сб, 2 апр. 2022 г. в 00:02, Cherio : > > I observed an announced change in behavior in version 9.0.60 (and later). > > My application has a Spring class loaded as a javax.servlet.Filter. It has > a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59 > the annotation was handled by Spring. Starting with Tomcat 9.0.60 behavior > changed. Now Tomcat attempts to take action on that method. The attempt > fails with "java.lang.IllegalArgumentException: Invalid > javax.annotation.PostConstruct annotation" exception and that results in > the whole application failing to start. 1. You have to provide a stacktrace for that error. Without a stacktrace the above are just words. The stack trace will show whether it is Tomcat code that is failing, or there is Spring code in the call chain. Also (if version of Tomcat is known as well), one can match it to source code and see at what step in the startup sequence it happened. 2. You say that it is a javax.servlet.Filter and it is coded so that Tomcat will not be able to create an instance of that class - proper creation of an instance of that filter must be done by Spring, so that Spring processes those PostConstruct annotations. Am I understanding you correctly? If so, then that Filter is not part of the web application itself (cannot be declared in web.xml, cannot be annotated with javax.servlet.annotation.WebFilter annotation). It should be instantiated by Spring and injected into the starting web application. Right? 3. Annotation scanning is configurable to some extent. It is possible to turn off some scanning, or configure it to scan/do not scan some jars. See the following wiki page for links: https://cwiki.apache.org/confluence/display/TOMCAT/HowTo+FasterStartUp#HowToFasterStartUp-JARscanning > I use PostConstruct in other Spring modules but it looks like Tomcat cares > only about classes it deals with directly. > > I do not see this change documented anywhere so I assume this may be a > regression or an undocumented bug fix or feature. > > Does anyone have more information about this? > Thanks! Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Aw: PostConstruct annotation in a filter since version 9.0.60
PostConstruct is for dependency-injection. A vanilla tomcat does no dependency injection. Can you confirm you have a vanilla tomcat? Kind regards Peter Rader -- Fachinformatiker AE / IT Software Developer Peter Rader Wilsnacker Strasse 17 10559 Berlin - GERMANY Tel: 0049 (0)30 / 6 29 33 29 6 Fax: 0049 (0)30 / 6 29 33 29 6 Handy: 0049 (0)176 / 87 521 576 Handy: 0049 (0)176 / 47 876 303 Gesendet: Freitag, 01. April 2022 um 23:02 Uhr Von: "Cherio" An: users@tomcat.apache.org Betreff: PostConstruct annotation in a filter since version 9.0.60 I observed an announced change in behavior in version 9.0.60 (and later). My application has a Spring class loaded as a javax.servlet.Filter. It has a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59 the annotation was handled by Spring. Starting with Tomcat 9.0.60 behavior changed. Now Tomcat attempts to take action on that method. The attempt fails with "java.lang.IllegalArgumentException: Invalid javax.annotation.PostConstruct annotation" exception and that results in the whole application failing to start. I use PostConstruct in other Spring modules but it looks like Tomcat cares only about classes it deals with directly. I do not see this change documented anywhere so I assume this may be a regression or an undocumented bug fix or feature. Does anyone have more information about this? Thanks! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
PostConstruct annotation in a filter since version 9.0.60
I observed an announced change in behavior in version 9.0.60 (and later). My application has a Spring class loaded as a javax.servlet.Filter. It has a method annotated with a PostConstruct annotation. Up until Tomcat 9.0.59 the annotation was handled by Spring. Starting with Tomcat 9.0.60 behavior changed. Now Tomcat attempts to take action on that method. The attempt fails with "java.lang.IllegalArgumentException: Invalid javax.annotation.PostConstruct annotation" exception and that results in the whole application failing to start. I use PostConstruct in other Spring modules but it looks like Tomcat cares only about classes it deals with directly. I do not see this change documented anywhere so I assume this may be a regression or an undocumented bug fix or feature. Does anyone have more information about this? Thanks!
