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 <ma...@apache.org> wrote: > > 5 Apr 2022 20:58:26 Cherio <che...@gmail.com>: > > > 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 > >
