Étrangeté lors du déploiement de l'application JRuby sous Jetty

Question

Ce problème est exaspérant et j'espère que quelqu'un peut me diriger dans la bonne direction. J'essaye de déployer une instance de Redmine à une servlet Jetty. J'ai créé la guerre en utilisant Warbler, j'ai créé le contexte, et il semble se déployer. Malheureusement, je vois les comportements suivants:

Si j'accède à mon application à son nom d'hôte configuré /, je vois une liste de répertoires du répertoire webapp.

Si j'accède à l'application en envoyant une requête GET à/braillewizard (le nom de contexte) avec un nom d'hôte configuré envoyé, l'application est exécutée.

Si je vous envoie une demande à/braillewizard avec un hôte: en-tête non inclus dans la liste des noms d'hôte, l'application est pas exécuté et je reçois un 404.

Il semblerait que j'ai partiellement l'hébergement virtuel configuré correctement, mais quelque chose ne va pas. La chose particulièrement gênante est que je suis exécutant une configuration similaire amende sur deux autres systèmes, y compris celui qui exécute Redmine, et tout fonctionne bien. La seule différence que je peux penser pour ce système est que je configure un vhost pour le FQDN du système alors que sur d'autres systèmes les hôtes sont sur des domaines accessoires. Je ne sais pas si c'est un facteur, mais mes tentatives pour se débarrasser de la configuration du contexte et aller avec l'application dans/root semblent toujours nécessiter un GET de/root.

Je suis aussi directement connecté au serveur Jetty, donc ce n'est pas un problème avec mon serveur web frontal.

Voici ma configuration de contexte:

<Configure class="org.mortbay.jetty.webapp.WebAppContext"> 
    <Set name="war"><SystemProperty name="jetty.home"/>/webapps/braillewizard.war</Set> 
    <Set name="contextPath">/</Set> 
    <Set name="virtualHosts"> 
    <Array type="java.lang.String"> 
     <Item>braillewizard.org</Item> 
     <Item>www.braillewizard.org</Item> 
    </Array> 
    </Set> 
</Configure> 

Et mon web.xml, produit par Fauvette:

<!DOCTYPE web-app PUBLIC 
    "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" 
    "http://java.sun.com/dtd/web-app_2_3.dtd"> 
<web-app> 

    <context-param> 
    <param-name>rails.env</param-name> 
    <param-value>production</param-value> 
    </context-param> 

    <context-param> 
    <param-name>public.root</param-name> 
    <param-value>/</param-value> 
    </context-param> 


    <filter> 
    <filter-name>RackFilter</filter-name> 
    <filter-class>org.jruby.rack.RackFilter</filter-class> 
    </filter> 
    <filter-mapping> 
    <filter-name>RackFilter</filter-name> 
    <url-pattern>/*</url-pattern> 
    </filter-mapping> 

    <listener> 
    <listener-class>org.jruby.rack.rails.RailsServletContextListener</listener-class> 
    </listener> 


</web-app> 

S'il y a autre chose que je pourrais donner, alors s'il vous plaît laissez-moi savoir. J'ai été googling pour une solution pendant des heures et ne trouvant rien.

Editer: OK, voici quelques détails de plus. L'idée que/contexte travaillé n'était pas exactement vrai. Au lieu de cela, l'application ne s'est pas chargée et je n'ai pas pu voir l'exception pour une raison quelconque. Divers réglages plus tard et le problème semble légèrement différent.

Il semble que/n'exécute aucune route liée à/dans l'application Rails. Plutôt, il déclenche une liste de répertoires pour le dossier webapp. Si je visite une URL directement dans mon application, à part/bien sûr, tout semble fonctionner correctement. L'appel de Jetty avec -DDEBUG en tant qu'argument JVM semble indiquer que RackHandler est en cours d'exécution, puis passe au gestionnaire par défaut. Cela semblerait cohérent avec un gestionnaire qui ne fonctionne pas, mais je ne suis pas sûr de savoir pourquoi je vois le comportement dans une version de ce déploiement et pas un autre.

Answer 1

Il a été suggéré à moi que ce comportement est dû à un bogue introduit dans l'adaptateur JRuby Rack 1.0.2, et que le correctif implique la rétrogradation à 1.0.1. Bien que je n'ai pas encore testé cette solution, il est cohérent avec la raison pour laquelle la version sur un serveur peut fonctionner alors qu'elle échoue sur un autre.

Je vais essayer cela et mettre à jour cette question avec les résultats plus tard, mais pour l'instant ce problème a à peu près mauté ma volonté de jouer avec ce truc pendant un moment.:) Pour le moment cela fonctionne parce que j'ai une réécriture d'URL en place, et c'est assez bon pour moi.

Answer 2

J'ai également rencontré ce problème lors du déploiement d'une application Rails à l'aide de Warbler with Jetty. Le correctif qui a fonctionné pour moi était de régler le paramètre dirAllowed sur le servlet par défaut à false, à savoir

<init-param> 
    <param-name>dirAllowed</param-name> 
    <param-value>false</param-value> 
</init-param> 

Je pense que le comportement par défaut est de tomber à travers de « ne peut pas trouver le fichier de bienvenue » à « montrer un répertoire list '- la modification de ce paramètre entraîne l'envoi de la demande à votre application Rails à la place.