I noticed that this happens after we stop and restart the context but does not happen right after we restart tomcat. To answer your question, there are other web applications on the server but those are not stopped or restarted.
Maybe it's because stopping the context did not correctly deregister the Soap service ? We followed the axis documentation instructions for when using tomcat and declared the AxisServlet in web.xml and assigned it a url-pattern. I am not sure if any additional steps are required for the servlet to correctly de-register ( the documentation mentions the use of a file called undeploy.wsdd but this only applies when running axis standalone ) There is the possibility that XMLGregorianCalendarImpl$DaysInMonth has 2 versions: the one in xercesImpl and the one in jdk-1.8 and maybe they conflict with each other although they are not in the same package ( org.apache.xerces.jaxp.datatype != com.sun.org.apache.xerces.internal.jaxp.datatype ) My automated test deploys a new version of the webapp and performs some testing in which it has to restart the context to continue testing. Then that exception occurs. I noticed that it does not happen when I have another version of the same webapp that stays deployed on the same tomcat. Thinking the bug was related to org.apache.axis.utils.XMLUtils.documentBuilder that uses a ThreadLocalDocumentBuilder, I tried adding a filter that I found online to close the leaks but that did not fix it. About this : > The trick to fixing this is figuring out what code is performing this JVM level registration and moving that code from the web application to $CATALINA_BASE/lib What java method call should I be searching for in libraries source code ? Simon On Tue, Apr 22, 2025 at 12:02 PM Mark Thomas <ma...@apache.org> wrote: > On 22/04/2025 16:44, Simon Arame wrote: > > <snip/> > > > What is strange is that although it says "this web application instance > has > > been stopped already", the web application is still running, end users > are > > still receiving 200 OKs from the web application. > > Any other web applications running on that Tomcat instance? > > Has the web application with the issue ever been restarted / reloaded? > > > We are not sure what causes this because it does not always happen, it is > > "intermittent". The SoapBindingStub is called from a JSP which is aimed > to > > simulate a call to a Soap service as if it was coming from outside of > this > > app. > > So the jsp that made the call received this 500 error from the Soap > service > > but this is unusual. > > What you are seeing is the web application attempting to use classes > that were loaded by a different/"older version of the current" web > application. > > This sort of thing can happen when a web application (or a library is > uses) registers something at the JVM level which then becomes a global > resource rather than a web application specific resource. > > The trick to fixing this is figuring out what code is performing this > JVM level registration and moving that code from the web application to > $CATALINA_BASE/lib > > If it is a library the application is using, this is relatively simple. > If it is the application then things get trickier. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
