Opened 17 months ago

Closed 17 months ago

Last modified 17 months ago

#2124 closed defect (fixed)

Susidns: cannot access addressbooks

Reported by: Reportage Owned by:
Priority: minor Milestone: 0.9.33
Component: apps/addressbook Version: 0.9.32
Keywords: susidns Cc:
Parent Tickets:

Description (last modified by 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)

Subtickets

Change History (8)

comment:1 Changed 17 months ago by Reportage

  • Description modified (diff)

comment:2 Changed 17 months ago by Reportage

  • Description modified (diff)

comment:3 Changed 17 months ago by zzz

  • Status changed from new to open

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

comment:4 Changed 17 months ago by Reportage

  • Resolution set to fixed
  • Status changed from open to closed

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.

comment:5 Changed 17 months ago by zzz

  • Priority changed from blocker to minor

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.

comment:6 Changed 17 months ago by 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

comment:7 Changed 17 months ago by 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.

comment:8 Changed 17 months ago by 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?

Note: See TracTickets for help on using tickets.