Hi, I'm having the same problem when trying to run Solr from the `solr- jetty` package in Trusty.
I discovered that the problem was solved in Debian, and I'm hope the solution will be backported to Ubuntu 14.04 soon. However, I'm here to share three **workarounds**. All of them consist on use both `jetty` and `libtomcat7-java`, but adding the `jsp-api-2.1-6.0.2.jar` file (or some other similar) to the Jetty classpath. I don't know if they have some problem. Use them at your own risk! Workaround 1 - Install the fix package proposed by vshn I found this workaround here: https://github.com/ckan/ckan/pull/2966 In short: ``` cd /tmp wget https://launchpad.net/~vshn/+archive/ubuntu/solr/+files/solr-jetty-jsp-fix_1.0.2_all.deb dpkg -i solr-jetty-jsp-fix_1.0.2_all.deb service jetty restart ``` This will install a proper jsp-lib jar that works (the file will be named `jsp-2.1-6.0.2.jar`, but is the same `jsp-api-2.1-6.0.2.jar` file from other solutions). Workaround 2 - Manually install the JSP jar Download the jar to your server. You can use one of these URLs: - http://www.java2s.com/Code/Jar/j/Downloadjspapi21602jar.htm - https://mvnrepository.com/artifact/org.mortbay.jetty/jsp-api-2.1/6.0.2 For example: ``` wget http://central.maven.org/maven2/org/mortbay/jetty/jsp-api-2.1/6.0.2/jsp-api-2.1-6.0.2.jar ``` Now, move it to a proper location inside the Jetty config dir. I did it this way: ``` mkdir /etc/jetty/extra-jars mv jsp-api-2.1-6.0.2.jar /etc/jetty/extra-jars ``` And add a line like this one in the Jetty `start.config` file: ``` echo "/etc/jetty/extra-jars/jsp-api-2.1-6.0.2.jar" >> /etc/jetty/start.config ``` And: ``` service jetty restart ``` Workaround 3 - Use the JSP jar file from the `libservlet2.5-java` package You can install `libservlet2.5-java` (files from Tomcat 6) even if `libtomcat7-java` is installed. There is no conflict here. This package will install also the JSP API 2.1 - 6.0.39-1. Now, let's add this file to the Jetty classpath: ``` echo "/usr/share/maven-repo/javax/servlet/jsp/jsp-api/2.1/jsp-api-2.1.jar" >> /etc/jetty/start.config ``` And: ``` service jetty restart ``` I did not test this last solution. If someone test it, please share the experience with us :). -- 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: Fix Released 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
