2017-09-04 6 views
0

Ich habe eine eingebettete Jetty Anwendung, in der Jetty 2 Dinge bietet:Embedded Jetty stoppt statischen Inhalt

  • einige HTML-Serving/JS-Dateien
  • eine REST-API freilegen, die meine Java Servlet
unterstützt

Die JS-Dateien führen REST-Aufrufe an das Servlet durch. Alles funktioniert wunderbar.

Was ich habe bemerkt, dass nach etwa einer Woche des Laufens, die API noch funktioniert, aber wenn ich versuche, eine HTML-Datei ich folgendes erhalten zu bekommen:

<html> 
<head> 
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> 
<title>Error 404 Not Found</title> 
</head> 
<body><h2>HTTP ERROR 404</h2> 
<p>Problem accessing /web/. Reason: 
<pre> Not Found</pre></p><hr><a href="http://eclipse.org/jetty">Powered by Jetty:// 9.4.4.v20170414</a><hr/> 

</body> 
</html> 

Was ist hier falsch gehen könnte ?

Nicht sicher, ob dies sinnvoll ist, aber ich stelle dies in einer Amazon AWS EC2-Instanz bereit. Ich kann mir nicht vorstellen, dass EC2 etwas tut, um das Verzeichnis/web verschwinden zu lassen.

Antwort

3

Ich gehe davon aus, dass Ihr XML-Fragment, das die Web-Anwendung wie folgt aussieht etwas einrichten:

<Call name="addHandler"> 
    <Arg> 
     <New class="org.eclipse.jetty.webapp.WebAppContext"> 
      <Set name="contextPath">/</Set> 
      <Set name="war">./path/to/webapp.war</Set> 
      <Set name="extractWAR">True</Set> 
      <Set name="copyWebInf">True</Set> 
     </New> 
    </Arg> 
</Call> 

Was passiert, ist, dass der Inhalt des Krieges in ein Verzeichnis in dem temporären Verzeichnis vom System angegeben extrahiert Eigenschaft java.io.tmpDir. Ohne dieses Verzeichnis selbst festzulegen, ist dies das temporäre Verzeichnis des Betriebssystems, z. /tmp unter Linux. Dies geschieht einmal während des Starts und es wird davon ausgegangen, dass das Verzeichnis während der gesamten Laufzeit des Prozesses existiert.

Auf Linux-Systemen haben Sie oft einen Cron-Job, der alte Einträge in/tmp löscht, die von diesen noch wichtigen Verzeichnissen, die von Jetty benötigt werden, ausgeht und zu diesen Fehlern führt. Auf die Servlets kann immer noch zugegriffen werden, da es sich um Java-Klassen handelt, die vom Klassenlader geladen werden. Das Entfernen der Jars, von denen sie ursprünglich geladen wurden, spielt keine Rolle (außer natürlich, dass Sie auf ein Servlet zugreifen, auf das zuvor nicht zugegriffen wurde)).

Eine Lösung hierfür ist die Angabe java.io.tmpDir selbst, die auf ein Verzeichnis unter Ihrer eigenen Kontrolle verweist.

+0

Kein XML-Code, aber ich programmiere genau die gleichen Dinge, um es einzurichten. Was Sie vorschlagen, macht Sinn. Leider wird diese Anwendung in vielen Umgebungen (Windows, RaspPi Linux, Amazon EC2 Linux, etc.) mit jeweils eigenen Macken eingesetzt werden. Gibt es etwas, das ich dem Temp dir setzen kann, das überall funktioniert? Vielen Dank für Ihre Hilfe. (und schnell!) –

+1

@Sander Wir verwenden Jetty in unserer Anwendung, so haben wir die Kontrolle über die Installation und setzen 'java.io.tmpDir' entsprechend, um sicherzustellen, dass das Problem nicht mehr auftritt. Eine kurze Google-Suche kam mit https://stackoverflow.com/questions/19232182/jetty-starts-in-c-temp/19232771#19232771 Vielleicht hilft das für Ihre – Lothar

+0

@SanderSmith Alternativ können Sie versuchen, 'ExtractWAR' zu setzen 'false' (behalte' copyWebInf' auf 'true', sonst funktionieren deine Servlets höchstwahrscheinlich nicht mehr, wenn Jetty das noch nicht behoben hat). Dies sollte das statische Material aus dem Dateisystem heraushalten. Aber ich habe das in der Praxis nicht versucht, also ist das nur eine Vermutung. – Lothar

Verwandte Themen