desktop-packages team mailing list archive

[Mauro <1508562@xxxxxxxxxxxxxxxxxx>]

IMHO trying to use Tomcat 7 Jasper/EL implementations with Jetty 6 is
not worth the effort, if it will ever work.

I mean, Jetty 6 implements Servlet 2.5/JSP 2.1/EL 2.1, which are the same specification versions implemented by Tomcat 6.
Tomcat 7, instead, implements Servlet 3.0/JSP 2.2/EL 2.2 specification versions, although it supports older versions, of course.
If the Tomcat 7 EL implementation requires an upgrade of the EL and Servlet API jars to properly work (as I experienced when I tried to just fix the symlinks), I'm really sceptical that this can be done without causing problems like multiple conflicting versions of the same JARs in classpath or other side effects on Jetty 6 standard operations. Maybe the new APIs and corresponding Tomcat implementations are perfectly backward-compatible, but setting this up properly could be not so easy (you're actually changing the core API JARs of the servlet container).

Going back to the original problem of the conflicting dependencies, I was wondering if it really is a "problem". I mean, just like you say that Tomcat 7 in Ubuntu can't be installed together with Tomcat 6, why not say that even Jetty 6 can't be installed together with Tomcat 7? We're talking about a servlet container which is EOL since Nov 2010 (see: https://wiki.eclipse.org/Jetty/Starting/Jetty_Version_Comparison_Table), so you may either:
1) remove it from recent Ubuntu/Debian official repositories
2) or just keep the old dependency and force the user to alternatively have just Jetty 6 or any other library that depends on a newer Tomcat version

After all, I think that if one needs to use Jetty 6 on a recent Ubuntu
(like me), it's because he needs to set up a dedicated system to run a
very old application that is not worth to update to run on a newer
version of Jetty (or any other recent version of another servlet
container, like Tomcat). In such a scenario, having the ability to run
much newer packaged software on the same system is most probably
useless.

The third solution might be to change the dependency against
libtomcat6-java to optional: after all, Jetty can run even without JSP
and EL support. The user then may choose to either a) leave these
features disabled, or b) to install libtomcat6-java to enable them or c)
to manually provide the required Jasper/EL JARs by himself for the same
purpose, if he needs to keep the conflicting libtomcat7-java package
installed instead.

-- 
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