Der Start des JAR-Jigs ist nach dem Upgrade von Spring Boot 1.3.7 auf 1.4.0 fehlgeschlagen

8

Nach dem Upgrade von Spring Boot 1.3.7 auf 1.4.0 können wir unsere Anwendung nicht mehr als ein einziges Jar-Build mit dem Spring Boot Maven Plugin starten. Unsere Anwendung ist eine kleine REST-Schnittstelle mit Jersey und Jetty. Wir verwenden Maven und unsere Pom-Datei ist ziemlich Standard Spring Boot.

Wir können die Anwendung weiterhin mit mvn spring-boot:run und innerhalb von Eclipse ausführen, aber wenn sie als einzelnes jar ausgeführt wird, beklagt sich Jersey ResourceFinder , dass sie .jar!/BOOT-INF/classes nicht finden kann.

Wenn ich das Jar entpacke, ist der Ordner BOOT-INF/classes vorhanden und enthält die erwarteten Klassen und Ressourcen.

Jede Hilfe wird geschätzt.

%Vor%     
oleb 10.08.2016, 13:50
quelle

3 Antworten

8

Aus dem Spring Boot 1.4 Versionshinweise :

  

Die Änderung des Layouts von ausführbaren Jars bedeutet, dass eine Einschränkung in Jerseys Klassenpfad-Scan jetzt ausführbare JAR-Dateien betrifft   sowie ausführbare Kriegsdateien. Um das Problem zu umgehen, sollten Klassen, die von Jersey gescannt werden sollen, in einem Jar verpackt und als Abhängigkeit in BOOT-INF/lib enthalten sein. Der Spring Boot Launcher sollte dann konfiguriert, um diese Jars beim Start zu entpacken , damit Jersey ihren Inhalt scannen kann.

    
Andy Wilkinson 10.08.2016, 14:50
quelle
2

Nur eine andere Lösung:

Obwohl Jersey Ihre Klassen in der neuen Version des Fat-Boot-Jars nicht scannen kann, können Sie den gleichen Effekt mit Spring-Classpath-Scan-Funktionen erzielen. Auf diese Weise können Sie ein Paket ähnlich wie ResourceConfig.packages() :

scannen %Vor%

Hinweis: Bitte sehen Sie sich die Quelle von org.glassfish.jersey.server.internal.scanning.AnnotationAcceptingListener an. Dies ist die Stammlösung und Sie können sehen, dass es dasselbe tut: Es wird nach Klassen gesucht, die mit @Path oder @Provider kommentiert wurden (es wird jedoch aufgrund des gebrochenen Scan-Mechanismus nichts gefunden).

Übrigens kann die Bean-basierte Methode, die von lanwen gepostet wird, klarer sein :) Füge einfach auch @Provider hinzu.

    
mihu86 17.03.2017 08:11
quelle
1

Bei Spring Boot (+ Jersey 2) kann es wie eine separate Konfigurationsklasse aussehen (um eine individuelle Ressourcenregistrierung zu erreichen):

%Vor%     
lanwen 13.09.2016 10:38
quelle