O Jetty interpreta JETTY_ARGS como nome de arquivo

Question

Estou executando o Jetty (versão "null 6.1.22") no Ubuntu 10.04. Está funcionando bem até que eu precise de suporte a JSP. De acordo com várias postagens do blog, preciso definir o JETTY_ARGS to OPTIONS=Server,jsp . No entanto, se eu colocar isso em /etc/default/jetty :

JETTY_ARGS=OPTIONS=Server,jsp

e reinicie o Jetty via /etc/init.d/jetty stop && /etc/init.d/jetty start , ele reporta sucesso, mas não aceita conexões. Eu percebo que ele registra algo em /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)

Isto é, o que quer que eu coloque em JETTY_ARGS, ele interprprime como um nome de arquivo dentro de /var/cache/jetty/tmp/ e tenta analisar esse arquivo como XML (ou analisa algum outro XML e tenta ler esse arquivo como um DTD? Não tenho certeza. Isso não parece fazer nenhum sentido para mim, especialmente porque esse diretório está totalmente vazio. Eu verifiquei isso com vários outros Strings, não só OPTIONS=Server,jsp .

Atualização:

De acordo com esta página no Eclipsepedia, eu deveria ser capaz de iniciar o Jetty invutando:

java -jar start.jar OPTIONS=Server,jsp

Isso cria exatamente a mesma exceção acima. Apenas invocando isso funciona, mas novamente sem suporte a JSP:

java -jar start.jar 

    

Answer 1

A parte em sua saída que diz org.mortbay.start.Main.start significa que você está executando uma versão Jetty (6.x ou anterior).

Qualquer documentação encontrada em eclipse.org/jetty/documentation/ ou wiki.eclipse.org/Jetty é inadequado para essa versão do Jetty.

Use a documentação arquivada em docs.codehaus.org/display/JETTY/Jetty+Documentation .

O fato de você ter um /etc/init.d/jetty significa que você provavelmente está executando o Jetty construído por uma das distribuições do Linux. Infelizmente, existem muitos bugs no processo de inicialização e inicialização nos vários pacotes de jetty criados pela distribuição Linux, especialmente com o /etc/init.d/jetty criado e empacotado. Os vários sistemas de rastreamento de bugs no debian e redhat são o local para o registro de bugs contra esses arquivos.

A linha de comando que você usou:

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

é para uso direto, autônomo, execução e é projetado apenas para trabalhar com a distribuição padrão de píer de dist.codehaus.org , o maven.org repo , ou download.eclipse.org .

Note que a distribuição de jetty vem com um bin / jetty.sh, que teve muitas correções para ser amigável para vários sistemas sysvinit.

No entanto, há várias correções de bugs e melhorias nos processos de inicialização do Jetty desde a mudança para o eclipse (Jetty 7+), incluindo a introdução de start.ini , semelhante a como o próprio eclipse pode ser configurado inicialização, que eliminou muitos desses problemas que você está enfrentando.

    

Answer 2

No caso de alguém (como eu) entender isso agora ...

Como joakime apontou, o Jetty 6 não usa a abordagem "OPTIONS = Server, jsp" para ativar o suporte a JSP. Olhando para a fonte do Jetty eu vi que ele simplesmente tenta localizar a classe org.apache.jasper.servlet.JspServlet no caminho da classe: se ele não puder encontrá-la, ela reclamará com a mensagem de erro mencionada acima.

Basta instalar o pacote libjetty-extra-java para corrigir o problema, pois ele adiciona links simbólicos em /usr/share/jetty/lib/jsp-2.1 aos JARs que são adicionados automaticamente ao caminho de classe do Jetty na inicialização. Para suporte a JSP, esses links simbólicos apontam para o Jasper JARS vindo do Tomcat, em particular de um pacote libtomcat?-java .

O problema adicional que encontrei no Ubuntu 14.04 é que o pacote libjetty-extra-java versão 6.1.26-1ubuntu1.1 vindo de trusty-updates depende do libtomcat7-java package (ao contrário da versão 6.1.26-1ubuntu1 vinda do universo, que depende de libtomcat6-java ), mas os links simbólicos em /usr/share/jetty/lib/jsp-2.1 para Jasper são quebrados, porque eles apontam para os nomes JAR fornecidos por libtomcat6-java , não aqueles fornecidos por libtomcat7-java . O mesmo se aplica ao commons-el.jar symlink, que também está quebrado. Uma vez que estes são corrigidos, outros erros sobre classes ausentes do Tomcat aparecem, provavelmente porque o Tomcat 7 Jasper tem dependências diferentes do Tomcat 6 Jasper.

Eu acabei de abrir o bug link para isso.

    

Answer 3

O Jetty é iniciado por bin / jetty.sh ( veja a fonte linha 477) onde o comando de execução é construído como:

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"

Como você pode ver, o JETTY_START é analisado antes de JETTY_ARGS. Isso significa que se JETTY_START não estiver configurado, o java tentará executar o arquivo retornado por JETTY_ARGS. Portanto, definir JETTY_HOME (usado em JETTY_START) como o valor correto deve corrigir seu problema.