2017-09-04 10 views
0

J'ai une application jetée intégrée où la jetée fournit 2 choses:Jetty intégré cesse du contenu statique

  • Au service certains fichiers HTML/JS
  • Révéler une API REST que mon Java Servlet soutient

les fichiers JS font REST appelle à la servlet. Tout fonctionne magnifiquement.

Ce que j'ai remarqué est que, après environ une semaine de fonctionnement, l'API fonctionne toujours, mais si je tente d'obtenir un fichier HTML que je reçois le texte suivant:

<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> 

Que pourraient aller mal ici ?

Je ne sais pas si cela est significatif, mais je déployer cela dans une instance Amazon AWS EC2. Je ne peux pas imaginer que EC2 fasse quelque chose pour faire disparaître le répertoire/web.

Répondre

3

Je suppose que votre XML fragment configuration de l'application Web ressemble à quelque chose comme ceci:

<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> 

Ce qui se passe est que le contenu de la guerre est extrait dans un répertoire dans le répertoire temporaire spécifié par le système Propriété java.io.tmpDir. Sans définir vous-même ce répertoire, il s'agit du répertoire temporaire du système d'exploitation, par ex. /tmp sur Linux. Ceci est fait une fois au démarrage et suppose que le répertoire existe pendant toute la durée du processus.

Sur les systèmes Linux, vous avez souvent un travail cron qui supprime les anciennes entrées dans/tmp "en prenant soin" de ces répertoires encore importants nécessaires à Jetty conduisant à ces erreurs. Les servlets sont toujours accessibles, car ils sont des classes Java chargés par le chargeur de classe, de sorte que le retrait des pots où ils ont été initialement chargés à partir, n'a pas d'importance (sauf bien sûr vous essayez d'accéder à un servlet qui n'a pas été consulté avant).

Une solution pour cela vous java.io.tmpDir préciser, pointant vers un répertoire sous votre propre contrôle.

+0

Aucun code XML, mais je programme exactement les mêmes choses pour le configurer. Ce que vous proposez est parfaitement logique. Malheureusement, cette application va être déployée dans de nombreux environnements (Windows, RaspPi Linux, Amazon EC2 Linux, etc.) avec leurs propres caprices. Y at-il quelque chose que je peux définir le temp dir pour que cela fonctionne partout? Merci beaucoup pour votre aide. (et rapide!) –

+1

@Sander Nous utilisons Jetty dans notre application donc nous avons le contrôle de l'installation et définissons 'java.io.tmpDir' en conséquence pour nous assurer que ce problème ne se produit plus. Une courte recherche Google a été créée avec https://stackoverflow.com/questions/19232182/jetty-starts-in-c-temp/19232771#19232771 Peut-être que cela vous aidera à – Lothar

+0

@SanderSmith Vous pouvez également essayer de définir 'extractWAR' sur 'false' (garder' copyWebInf' à 'true' sinon vos servlets ne fonctionneront probablement plus si Jetty n'a pas encore corrigé cela). Cela devrait garder les choses statiques hors du système de fichiers. Mais je n'ai pas essayé cela en pratique, donc c'est juste une supposition. – Lothar