Susidns: cannot access addressbooks

[Reportage]

0.9.32-16 / win 10 64 & Linux 4.14 64 / jre oracle 1.8.0

HTTP ERROR 500

Problem accessing /susidns/addressbook. Reason:

    Server Error

Caused by:

javax.servlet.ServletException: java.lang.NoSuchMethodError: org.apache.jasper.runtime.JspRuntimeLibrary.releaseTag(Ljavax/servlet/jsp/tagext/Tag;Lorg/apache/tomcat/InstanceManager;Z)V
	at org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:909)
	at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:838)
	at i2p.susi.dns.jsp.addressbook_jsp._jspService(addressbook_jsp.java:631)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
	at net.i2p.servlet.filters.XSSFilter.doFilter(XSSFilter.java:30)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
	at net.i2p.router.web.HostCheckHandler.handle(HostCheckHandler.java:78)
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
	at org.eclipse.jetty.server.Server.handle(Server.java:499)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NoSuchMethodError: org.apache.jasper.runtime.JspRuntimeLibrary.releaseTag(Ljavax/servlet/jsp/tagext/Tag;Lorg/apache/tomcat/InstanceManager;Z)V
	at i2p.susi.dns.jsp.addressbook_jsp._jspx_meth_c_005fforEach_005f0(addressbook_jsp.java:680)
	at i2p.susi.dns.jsp.addressbook_jsp._jspService(addressbook_jsp.java:187)
	... 27 more

Caused by:

java.lang.NoSuchMethodError: org.apache.jasper.runtime.JspRuntimeLibrary.releaseTag(Ljavax/servlet/jsp/tagext/Tag;Lorg/apache/tomcat/InstanceManager;Z)V
	at i2p.susi.dns.jsp.addressbook_jsp._jspx_meth_c_005fforEach_005f0(addressbook_jsp.java:680)
	at i2p.susi.dns.jsp.addressbook_jsp._jspService(addressbook_jsp.java:187)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
	at net.i2p.servlet.filters.XSSFilter.doFilter(XSSFilter.java:30)
	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
	at net.i2p.router.web.HostCheckHandler.handle(HostCheckHandler.java:78)
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
	at org.eclipse.jetty.server.Server.handle(Server.java:499)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:258)
	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
	at java.lang.Thread.run(Unknown Source)

[zzz]

Where did you get -16 from, did you build it yourself or get it from somebody else?
This is most likely a Jetty mismatch, you must use 'ant updaterWithJetty' if you build it yourself, or ask the person who built it to do that.

See ​http://zzz.i2p/topics/2473
See ​http://zzz.i2p/topics/2477

[Reportage]

Building with Jetty updates fixed the issue. It might be an idea to add some extra logic to the update mechanism that validates the existing Jetty version and generates a less cryptic error if an out-of-date Jetty is found. Marking closed/fixed.

[zzz]

to be more correct, we updated both Jetty (a minor update) and Tomcat (a major update). Both are included in the 'updaterWithJetty' target. It was Tomcat that caused the problem. We rarely do it, but as you can see in the zzz.i2p threads linked above I'm trying to get everybody that builds updates for others to always use that target.

It's difficult to come up with some generalized test to catch out-of-date libs. I've looked before and could never find a way to get the Tomcat version programmatically, that's why we don't display it on /logs. And actually the root cause is changing the taglib implementation, which is another story.

Anyway, glad we figured it out.

[Reportage]

Maybe this thread on stackoverflow will help with displaying the Tomcat version on /logs? ​https://stackoverflow.com/questions/14925073/how-to-find-out-running-tomcat-version

[zzz]

Thanks for the link. Unfortunately, in our setup, application.getServerInfo() returns the Jetty version. That's because Jetty is our server (not catalina), and we're just using Tomcat for some lower-level servlet libraries.

In other news, I did make contact with the bobthebuilder.i2p op, and he's made the change to updater200WithJetty, see the threads over on zzz.i2p.

[Reportage]

Assuming that the version of Tomcat indicated by the directory suffix in /apps/jetty/apache-tomcat-8.5.23 is always correct, could this not be grepped at compile time and written to a text file that could then be read to indicate the Tomcat version in the console?