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 <ma...@apache.org> 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 <che...@gmail.com>: > > > 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
