Le plugin Jetty Maven ignore le fichier webdefault.xml personnalisé

Question

J'essaie de contourner le problème courant de verrouillage des fichiers statiques par Jetty sous Windows avec la technique de réglage useFileMappedBuffer à false dans webdefault.xml.Malheureusement, à chaque fois, Jetty ne récupère pas mon webdefault.xml personnalisé.

J'utilise Apache Maven 3.0.2.J'ai essayé d'utiliser le plugin-maven-jetty (v6.1.26) et plugin-jetty-maven (v8.0.0.M2) mais sans aucune différence.J'ai également essayé de nettoyer et de reconstruire avant d'exécuter Jetty.

J'ai vérifié à chaque fois que mon webdefault.xml provenait de la même version que le plugin et avait les paramètres corrects, à savoir en changeant uniquement ce paramètre de vrai à faux :

...
<init-param>
  <param-name>useFileMappedBuffer</param-name>
  <param-value>false</param-value>
</init-param>
...

Et voici à quoi ressemble ma section du plugin pom.xml Jetty :

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
    <configuration>
        <contextPath>/</contextPath>
        <webDefaultXml>src/main/resources/webdefault.xml</webDefaultXml>
    </configuration>
</plugin>

J'ai également essayé de modifier le chemin d'accès à mon fichier :

<webDefaultXml>${basedir}/src/main/resources/webdefault.xml</webDefaultXml>

Partout où j'ai vu cette solution exacte et il semble que cela fonctionne pour d'autres (même si j'ai trouvé un cas où quelqu'un a eu mon problème).Le démarrage de Jetty a ceci dans le résultat :

> mvn jetty:run
...
[INFO] Web defaults = org/eclipse/jetty/webapp/webdefault.xml
[INFO] Web overrides = none
...

Cela me fait penser en outre qu'il n'est pas appliqué.Tous les autres chemins sont corrects dans la sortie.

Mon problème le plus direct que je vois pendant l'exécution de Jetty est que chaque fois que je modifie un fichier statique (JavaScript, CSS, etc.) avec IntelliJ IDEA 10, j'obtiens ce message d'erreur :

Cannot save file:
D:\...\... (The requested operation cannot be performed on a file with a user-mapped section open)

Après avoir arrêté Jetty, cela enregistre très bien.Cela arrive à chaque fois.

Avez-vous une idée de ce que je pourrais faire de mal ? Merci d'avance.

Answer 1

J'ai trouvé une documentation entièrement différente pour le nouveau plugin Jetty jetty-maven-plugin (v8.0.0.M2) et il semble que le nom de la configuration ait changé :

http://wiki.eclipse.org/Jetty/Reference/webdefault.xml#Using_the_Jetty_Maven_Plugin

<project>
    ...
    <plugins>
        <plugin>
            ...
            <artifactId>jetty-maven-plugin</artifactId>
            <configuration>
                <webAppConfig>
                  ...
                  <defaultsDescriptor>/my/path/to/webdefault.xml</defaultsDescriptor>
                </webAppConfig>
            </configuration>
        </plugin>
        ...
    </plugins>
    ...
</project>

Cela semble maintenant fonctionner pour le plugin le plus récent.Je ne sais toujours pas pourquoi le plugin v6 ne récupère pas la configuration personnalisée.

Answer 2

La seule solution que j'ai trouvée et qui fonctionnait avec maven-jetty-plugin 6.1.24 était la suivante :http://false.ekta.is/2010/12/jettyrun-maven-plugin-file-locking-on-windows-a-better-way/

Answer 3

La documentation Jetty décrit trois façons de procéder (à partir de Jetty 9) :

https://www.eclipse.org/jetty/documentation/current/troubleshooting-locked-files-on-windows.html

J'ai utilisé avec succès la méthode init-param dans Maven :

        <!-- Running an embedded server for testing/development -->
        <plugin>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-maven-plugin</artifactId>
            <version>9.4.9.v20180320</version>

            <configuration>
                <webApp>
                    <_initParams>
                        <org.eclipse.jetty.servlet.Default.useFileMappedBuffer>false</org.eclipse.jetty.servlet.Default.useFileMappedBuffer>
                    </_initParams>
                </webApp>
            </configuration>

        </plugin>