NoClassDefFoundError with Servlet Filter causes application to fail

Hi!

I am trying to use the specialagent to instrument a legacy application. While some of the plugins are working, the javax servlet one is causing the application to fail.

This is the error being thrown in the application:

PluginManifest.get(/var/folders/3g/sk2hj63d485cxd72d4lt4088dz68_2/T/opentracing-specialagent38983911031602862/META-INF/plugins/servlet-1.5.3-SNAPSHOT.jar </var/folders/3g/sk2hj63d485cxd72d4lt4088dz68_2/T/opentracing-specialagent38983911031602862/META-INF/plugins/servlet-1.5.3-SNAPSHOT.jar>): PluginManifest@4d6aae69
SpecialAgent#linkRule("servlet"[4], org.codehaus.plexus.classworlds.realm.ClassRealm@28344389): compatible = true [cached]
PluginManifest.get(/var/folders/3g/sk2hj63d485cxd72d4lt4088dz68_2/T/opentracing-specialagent38983911031602862/META-INF/plugins/servlet-1.5.3-SNAPSHOT.jar </var/folders/3g/sk2hj63d485cxd72d4lt4088dz68_2/T/opentracing-specialagent38983911031602862/META-INF/plugins/servlet-1.5.3-SNAPSHOT.jar>): PluginManifest@4d6aae69
SpecialAgent#linkRule("servlet"[4], org.codehaus.plexus.classworlds.realm.ClassRealm@28344389): compatible = true [cached]
Dec 14, 2019 5:27:59 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [default] in context with path [] threw exception [Filter execution threw an exception] with root cause
java.lang.ClassNotFoundException: io.opentracing.contrib.specialagent.rule.servlet.ServletContextAgentRule
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1713)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558)
	at <proprietary filter>
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)

-------> Intercept from: public void org.apache.catalina.connector.Response.setStatus(int)
-------> Intercept from: public void org.apache.catalina.connector.Response.setStatus(int)
Dec 14, 2019 5:27:59 PM org.apache.coyote.http11.AbstractHttp11Processor process
SEVERE: Error processing request
java.lang.NoClassDefFoundError: io/opentracing/contrib/specialagent/rule/servlet/FilterAgentIntercept
	at org.apache.catalina.connector.Response.setStatus(Response.java:1488)
	at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:424)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:179)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:745)

Some details of the project setup:

Maven Version:

• Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 14:51:28+0100)

Java Version:

• 1.7.0_80, vendor: Oracle Corporation

Servlet Version:

• javax.servlet:servlet-api:jar:2.5:provided

Tomcat Version:

• org.apache.tomcat:tomcat-coyote:jar:7.0.56:provided
• org.apache.tomcat:tomcat-servlet-api:jar:7.0.56:provided
• org.apache.tomcat:tomcat-api:jar:7.0.56:provided

I noticed that the tomcat dependencies were for a version older than the one listed in the specialagent documentation, so I tried to add 7.0.56 in the servlet rule’s tests, and built a custom agent. The tests passed. The application, however, is still failing.

Attached is the file with the references to the servlet plugin that I identified in the agent startup: servlet-references.log

In the logs above I see that the rule is loaded, and the class is added to the Class Loaders, which just adds to the confusion as to why the class is not found.

Let me know if there is any other information that I could add to help troubleshoot this. Any hints that would allow me to figure out what is the problem would be greatly appreciated.

Thanks in advance.

[pc-alves]

Hi @safris. Things went a bit slow over the holidays. However, we did create a small app to try to replicate the issue. While doing so, we noticed that the errors I reported were only obtained while running the maven version that the legacy project requires (3.0.5). When we run it with maven 3.6.3 everything works fine.

As we don’t actually need maven to run the app (we just deploy it to tomcat in production), we are now running tests by deploying the application to tomcat locally to confirm our assumptions. For one, we now see the servlet spans with Java 1.8, which is an improvement from our starting point. Will keep you up to date on our latest findings.

[safris]

Thank you for the update @zeitlinger. I will close this issue, and will look out for your subsequent issues.