Spring Boot JAR mit Maven mit RequiresUnpack funktioniert nicht

Question

Ich glaube, ich habe in der folgenden Ausgabe Jersey doesn't always work with Spring Boot fat jars laufen. Die Problemumgehung sollte sein, die Jersey dependencies in POM zu requiresUnpack zu setzen.

Mein POM sieht wie folgt aus:

<?xml version="1.0" encoding="UTF-8"?> 
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
    <modelVersion>4.0.0</modelVersion> 

    <groupId>net.hagstrom</groupId> 
    <artifactId>demo</artifactId> 
    <version>0.0.1-SNAPSHOT</version> 
    <packaging>jar</packaging> 

    <name>demo</name> 
    <description>Demo project for Spring Boot</description> 

    <parent> 
     <groupId>org.springframework.boot</groupId> 
     <artifactId>spring-boot-starter-parent</artifactId> 
     <version>1.4.3.RELEASE</version> 
     <relativePath/> <!-- lookup parent from repository --> 
    </parent> 

    <properties> 
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
     <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> 
     <java.version>1.8</java.version> 
    </properties> 

    <dependencies> 
     <dependency> 
      <groupId>org.springframework.boot</groupId> 
      <artifactId>spring-boot-starter-jersey</artifactId> 
     </dependency> 

     <dependency> 
      <groupId>mysql</groupId> 
      <artifactId>mysql-connector-java</artifactId> 
      <scope>runtime</scope> 
     </dependency> 
     <dependency> 
      <groupId>org.springframework.boot</groupId> 
      <artifactId>spring-boot-starter-test</artifactId> 
      <scope>test</scope> 
     </dependency> 
    </dependencies> 

    <build> 
     <plugins> 
      <plugin> 
       <groupId>org.springframework.boot</groupId> 
       <artifactId>spring-boot-maven-plugin</artifactId> 
       <configuration> 
        <requiresUnpack> 
         <dependency> 
          <groupId>org.glassfish.jersey.containers</groupId> 
          <artifactId>jersey-container-servlet</artifactId> 
         </dependency> 
         <dependency> 
          <groupId>org.glassfish.jersey.core</groupId> 
          <artifactId>jersey-client</artifactId> 
         </dependency> 
        </requiresUnpack> 
       </configuration> 
       <version>1.4.3.RELEASE</version> 
       <executions> 
        <execution> 
         <goals> 
          <goal>repackage</goal> 
         </goals> 
        </execution> 
       </executions> 
      </plugin> 
     </plugins> 
    </build> 
</project> 

Aber ich bekomme immer noch die folgende Fehlermeldung, wenn ich versuche, die JAR-Datei ausführen, die ich mit mvn package gebaut:

2017-01-13 10:44:28.229 ERROR 9289 --- [ost-startStop-1] o.s.b.c.embedded.tomcat.TomcatStarter : Error starting Tomcat context. Exception: org.springframework.beans.factory.UnsatisfiedDependencyException. Message: Error creating bean with name 'org.springframework.boot.autoconfigure.jersey.JerseyAutoConfiguration': Unsatisfied dependency expressed through constructor parameter 1; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jerseyConfig' defined in URL [jar:file:/home/mikael/Dev/Java/Java%20Programs/springBootDemo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/net/hagstrom/JerseyConfig.class]: Bean instantiation via constructor failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [net.hagstrom.JerseyConfig]: Constructor threw exception; nested exception is org.glassfish.jersey.server.internal.scanning.ResourceFinderException: java.io.FileNotFoundException: /home/mikael/Dev/Java/Java Programs/springBootDemo/target/demo-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes (No such file or directory) 

Ausführen des JAR, das ich gebaut in der IDE mit Artifacts funktioniert gut.

Ist etwas falsch in meinem POM oder die Art, wie ich das JAR mit Maven baue?

Answer 1

Dies wurde möglicherweise bereits behoben. Ich habe ein paar Blog-Kommentare über Erstellen von APIs veröffentlicht mit Spring Boot, Jersey 2 und Docker und dokumentieren sie Swagger abrufbar unter Verwendung von: http://tech.asimio.net/2016/04/05/Microservices-using-Spring-Boot-Jersey-Swagger-and-Docker.html und http://tech.asimio.net/2016/05/07/Documenting-multiple-REST-API-versions-using-Spring-Boot-Jersey-and-Swagger.html, beide mit Quellcode begleiten und ich brauchte nicht zu unpack und repackageJersey 2 Abhängigkeiten.

Auf der anderen Seite, wenn ich auf der Begleit-Quellcode für einen anderen Blog über Services Registration and Discovery using Spring Cloud, Eureka, Ribbon and Feign, arbeitete ich die Integration Spring Boot und Jersey 1 (Jersey 1 keinen Spring Boot Starter Ich erinnere mich an herum arbeiten Auspacken Jersey 1 eine Abhängigkeiten erforderlich, um ein Multi-Modul Maven Projekt für diesen speziellen API-Dienst zu erstellen.

Answer 2

fand ich das Problem.

Frühlings-Boot 1.4 geändert, um die innere Struktur Jar diezu erleichternSpring Boot Bootstrap-Prozess.

https://github.com/spring-projects/spring-boot/issues/1468#issuecomment-267357809

Sie können diese Version 1.4.3 lassen: Fett-jar

<parent> 
     <groupId>org.springframework.boot</groupId> 
     <artifactId>spring-boot-starter-parent</artifactId> 
     <version>1.4.3.RELEASE</version> 
     <relativePath/> <!-- lookup parent from repository --> 
    </parent> 

Aber der Frühling-boot-Trikot ohne Fehler ausführbar sein `s brauchen Plugin-Version herabzustufen 1.3.8 gefällt das:

Answer 3

Das Problem ist, dass Jersey Klassen im neuen "fat boot jar" nicht scannen kann. Dies tritt auf, wenn Sie versuchen, die packages("some.package.to.scan")-Methode der Klasse ResourceConfig zu verwenden.

Sie können jedoch den gleichen Effekt mit Spring-Klassenpfad-Scan-Einrichtungen erzielen. So können Sie ein Paket zu config.packages Ähnlich scannen():

ClassPathScanningCandidateComponentProvider scanner = new ClassPathScanningCandidateComponentProvider(false); 
scanner.addIncludeFilter(new AnnotationTypeFilter(Provider.class)); 
scanner.addIncludeFilter(new AnnotationTypeFilter(Path.class)); 
config.registerClasses(scanner.findCandidateComponents("your.package.to.scan").stream() 
      .map(beanDefinition -> ClassUtils.resolveClassName(beanDefinition.getBeanClassName(), config.getClassLoader())) 
      .collect(Collectors.toSet())); 

Hinweis: bitte einen Blick auf die Quelle org.glassfish.jersey.server.internal.scanning.AnnotationAcceptingListener haben. Dies ist die Stammlösung, und Sie können sehen, dass es das gleiche tut: es sucht nach Klassen, die mit @Path oder @Provider kommentiert sind (es gelingt jedoch nichts zu finden, weil der Scan-Mechanismus kaputt ist).

(Mit Hilfe der ältere Version der Boot-Plugin auch für mich gearbeitet, aber ich versuchte, es zu vermeiden.)