Wie hoch ist die erwartete Ressourcenladepriorität, wenn Jetty setExtraClasspath verwendet wird?

Question

Wird erwartet, dass Ressourcen in .jar-Dateien, die über die WebAppContext.setExtraClasspath-Methode von Jetty enthalten sind, bevorzugt für Ressourcen mit demselben Namen/Pfad innerhalb der .war-Datei geladen werden?

-

ich dabei bin einige Abhängigkeiten von .war-Dateien zu bewegen und mit ihnen statt über WebAppContext der setExtraClasspath Methode (http://www.eclipse.org/jetty/documentation/current/jetty-classloading.html#using-extra-classpath-method)

Während Dabei lief ich in ein Problem, bei dem Eine der jetzt verschobenen .jar-Dateien enthält eine Datei namens ehcache.xml, die gegenüber der in .war bevorzugt zu lesen scheint, wenn verwendet wird.

Nun, da ich weiß, daß der Fall zu sein, ich denke, es ist keine große Unannehmlichkeit für mich, wenn ich die Datei umbenennen muß eindeutig sein, aber ich denke, ich frage mich ...

• Am Ich lade die Ressource falsch (und wenn ja, wie kann ich es tun, um. War hat Priorität)?

• War es nur Glück, dass die .war-Version Vorrang hatte (wenn das fragliche .jar im .war-Format enthalten war)?

• Ist das ein erwarteter Nachteil von setExtraClasspath, mit dem ich einfach leben muss?

• Habe ich irgendwo Unterlagen vergessen, die das für mich geklärt hätten?

Answer 1

Dank Jan on the jetty-user's list ...

AFAIK wir keine spezielle Handhabung der zusätzlichen Classpath. Die Reihenfolge von Pfaden, die dem URLClassLoader hinzugefügt werden, die die Webapp Classloader ist.

• zusätzliche Classpath
• WEB-INF/classes
• WEB-INF/lib/* jar

Die webapp classloader getResource (String) -Methode sieht zuerst in sich selbst vor dem Suchen in der übergeordneten (um Servlet-Spezifikation invertiert Classloading-Anforderungen zu entsprechen), aber die Suche ist alles delegiert an die URLClassLoader, so ist es, was auch immer die jvm hat implementiert, die nach GrepCode http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/misc/URLClassPath.java#URLClassPath.0urls sieht aus wie die Suchreihenfolge wird wie oben sein.

Traurig für meinen Fall, aber macht Sinn.