Jetty interprets JETTY_ARGS as file name

Question

I'm running Jetty (version "null 6.1.22") on Ubuntu 10.04. It's running fine until I need JSP support. According to several blog posts I need to set the JETTY_ARGS to OPTIONS=Server,jsp. However, if I put this into /etc/default/jetty:

JETTY_ARGS=OPTIONS=Server,jsp

and restart Jetty via /etc/init.d/jetty stop && /etc/init.d/jetty start, it reports success, but does not accept connections. I notices that it logs something to /usr/share/jetty/logs/out.log:

2012-09-11 11:19:05.110:WARN::EXCEPTION 
java.io.FileNotFoundException: /var/cache/jetty/tmp/OPTIONS=Server,jsp (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:137)
at java.io.FileInputStream.<init>(FileInputStream.java:96)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:87)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:178)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:630)
at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:189)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:776)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:741)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:392)
at org.mortbay.xml.XmlParser.parse(XmlParser.java:188)
at org.mortbay.xml.XmlParser.parse(XmlParser.java:204)
at org.mortbay.xml.XmlConfiguration.<init>(XmlConfiguration.java:109)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:969)
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:616)
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:616)
at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)

That is, whatever I put into JETTY_ARGS, it inteprets is as a filename inside /var/cache/jetty/tmp/ and tries to parse that file as XML (or does it parse some other XML and tries to read that file as a DTD? I'm not sure.). This doesn't seem to make any sense to me, especially since that directory is entirely empty. I've verified this with several other Strings, not only OPTIONS=Server,jsp.

Update:

According to this page in the Eclipsepedia, I should be able to start Jetty by invking:

java -jar start.jar OPTIONS=Server,jsp

This creates exactly the same exception as above. Just invoking this works, but again without JSP support:

java -jar start.jar 

Answer 1

The part in your output that says org.mortbay.start.Main.start means you are running a version of Jetty (6.x or earlier).

Any documentation you found at eclipse.org/jetty/documentation/ or wiki.eclipse.org/Jetty is inappropriate for that version of Jetty.

Use the archived documentation at docs.codehaus.org/display/JETTY/Jetty+Documentation instead.

The fact that you have a /etc/init.d/jetty means you are likely running jetty built by one of the linux distributions. There are unfortunately many bugs to be found in the startup and initialization process in the various linux distribution created jetty bundles, especially with the created and bundled /etc/init.d/jetty. The various bug tracking systems at debian and redhat are the place to file bugs against these files.

The command line you used:

$ java -jar start.jar OPTIONS=Server,jsp

is for direct, stand alone, execution, and is only designed to work with the standard jetty distribution from dist.codehaus.org, the maven.org repo, or download.eclipse.org.

Note that the jetty-distribution comes with a bin/jetty.sh, which has had many fixes to be friendly for various sysvinit systems.

However, that being said, there have many bug fixes and improvements with the startup processes in Jetty since moving to eclipse (Jetty 7+), including the introduction of a start.ini, similar to how eclipse itself can be configured for startup, which eliminated many of these kinds of issues you are experiencing.

Answer 2

In case someone (like me) gets on this now...

As joakime pointed out, Jetty 6 does not use the "OPTIONS=Server,jsp" approach to enable JSP support. Looking at the Jetty source I saw that it simply tries to locate the class org.apache.jasper.servlet.JspServlet on the classpath: if it can't find it, it complains with the aforementioned error message.

Simply installing the package libjetty-extra-java is supposed to fix the problem, because it adds symlinks in /usr/share/jetty/lib/jsp-2.1 to JARs that are automatically added to Jetty classpath on startup. For JSP support, these symlinks point to Jasper JARS coming from Tomcat, in particular from a libtomcat?-javapackage.

The additional problem I found in Ubuntu 14.04 is that the package libjetty-extra-java version 6.1.26-1ubuntu1.1 coming from trusty-updates depends on libtomcat7-java package (contrary to version 6.1.26-1ubuntu1 coming from universe, which depends on libtomcat6-java), but the symlinks in /usr/share/jetty/lib/jsp-2.1 for Jasper are broken, because they point to the JAR names provided by libtomcat6-java, not those provided by libtomcat7-java. The same applies to commons-el.jar symlink, which is also broken. Once these are fixed, other errors about missing Tomcat classes appear, probably because Tomcat 7 Jasper has different dependencies than Tomcat 6 Jasper.

I just opened bug https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/1508562 for this.

Answer 3

Jetty is started by bin/jetty.sh (see source line 477) where the run command is built like:

JETTY_START=$JETTY_HOME/start.jar
[ ! -f $JETTY_START ] && JETTY_START=$JETTY_HOME/lib/start.jar

RUN_ARGS="$JAVA_OPTIONS -jar $JETTY_START $JETTY_ARGS $CONFIGS"
RUN_CMD="$JAVA $RUN_ARGS"

As you can see JETTY_START is parsed before JETTY_ARGS. That means if JETTY_START is not set, java tries to run the file returned by JETTY_ARGS. So setting JETTY_HOME (used in JETTY_START) to the right value should fix your issue.