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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
