← Back to team overview

desktop-packages team mailing list archive

[Bug 1508562] Re: Broken symlinks for JSP support in libjetty-extra-java version 6.1.26-1ubuntu1.1

 

Hello and thanks for reporting this issue.

>I was wondering why the dependency has been upgraded from
libtomcat6-java to libtomcat7-java.

I see that you have found bug 1286779 which contains more details about
the update in 14.04. The short version is that conflicts between tomcat6
and tomcat7 made it harder to install packages together. There seemed to
be a simple patch which changed the dependency so that was picked from
the later version and applied.

Unfortunately, I now see that it has caused a regression and I am of
course sorry about that.

I looked further into this, since newer versions of libjetty-extra-java
contain the same patch and found that the symlinks are also broken on
Ubuntu 15.10 and also Debian Sid. So this is actually affecting all
newer versions of the package. :(

I've forwarded the bug to Debian so hopefully the package maintainers
will take a look at this. One thing is of course the 14.04 update (which
of course is a shame), but the issue will need to be resolved in general
for newer versions. So I believe that once we have a solution for this
we can look at whether that should be applied to 14.04 as well, or
whether it should be rolled back to tomcat6 (which of course would re-
introduce the package conflicts.)


** Changed in: jetty (Ubuntu)
       Status: New => Confirmed

** Tags added: trusty vivid wily

** Bug watch added: Debian Bug tracker #802716
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802716

** Also affects: jetty (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802716
   Importance: Unknown
       Status: Unknown

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to jetty in Ubuntu.
https://bugs.launchpad.net/bugs/1508562

Title:
  Broken symlinks for JSP support in libjetty-extra-java version
  6.1.26-1ubuntu1.1

Status in jetty package in Ubuntu:
  Confirmed
Status in jetty package in Debian:
  Unknown

Bug description:
  Version 6.1.26-1ubuntu1.1 of libjetty-extra-java has changed the
  dependency for Jasper (to enable JSP support) from libtomcat6-java
  package to libtomcat7-java.

  The Jasper JAR files provided by libtomcat7-java have different names:
  tomcat-jasper.jar instead of jasper.jar
  tomcat-jasper-el.jar instead of jasper-el.jar

  However the symlinks provided by the libjetty-extra-java in
  /usr/share/jetty/lib/jsp-2.1 folder have not been updated, as they
  still point to /usr/share/java/jasper.jar and /usr/share/java/jasper-
  el.jar: hence, the symlinks are broken and Jetty starts without JSP
  support (even if the libjetty-extra-java package is installed).

  Changing the symlinks to point to the updated file names bring to
  NoClassDefFoundExceptions, probably because of different dependencies
  of Tomcat 7 Jasper libraries:

  [main] WARN org.mortbay.log - failed ContextHandlerCollection@37403a09: java.lang.NoClassDefFoundError: org/apache/tomcat/PeriodicEventListener
  [main] INFO org.mortbay.log - Opened /var/log/jetty/2015_10_21.request.log
  [main] WARN org.mortbay.log - failed HandlerCollection@4c3db835: java.lang.NoClassDefFoundError: org/apache/tomcat/PeriodicEventListener
  [main] ERROR org.mortbay.log - Error starting handlers
  java.lang.NoClassDefFoundError: org/apache/tomcat/PeriodicEventListener
          at java.lang.ClassLoader.defineClass1(Native Method)
          at java.lang.ClassLoader.defineClass(ClassLoader.java:643)
          at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
          at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
          at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
          at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:268)
          at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:401)
          at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
          at org.mortbay.util.Loader.loadClass(Loader.java:91)
          at org.mortbay.util.Loader.loadClass(Loader.java:71)
          at org.mortbay.jetty.webapp.WebXmlConfiguration.initServlet(WebXmlConfiguration.java:510)
          at org.mortbay.jetty.webapp.WebXmlConfiguration.initWebXmlElement(WebXmlConfiguration.java:335)
          at org.mortbay.jetty.webapp.WebXmlConfiguration.initialize(WebXmlConfiguration.java:289)
          at org.mortbay.jetty.webapp.WebXmlConfiguration.configure(WebXmlConfiguration.java:222)
          at org.mortbay.jetty.webapp.WebXmlConfiguration.configureDefaults(WebXmlConfiguration.java:162)
          at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1262)
          at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:519)
          at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
          at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
          at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
          at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
          at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
          at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
          at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
          at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
          at org.mortbay.jetty.Server.doStart(Server.java:224)
          at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
          at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:622)
          at org.mortbay.start.Main.invokeMain(Main.java:194)
          at org.mortbay.start.Main.start(Main.java:534)
          at org.mortbay.jetty.start.daemon.Bootstrap.start(Bootstrap.java:30)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
          at java.lang.reflect.Method.invoke(Method.java:622)
          at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
  Caused by: java.lang.ClassNotFoundException: org.apache.tomcat.PeriodicEventListener
          at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:323)
   
  Please note that WebXmlConfiguration.java:510 is exactly the line in which the class for JSP support is loaded.
  I'll try to see if I can make this work with Tomcat 7 Jasper, but I was wondering why the dependency has been upgraded from libtomcat6-java to libtomcat7-java.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1508562/+subscriptions


References