Vaadin, Jetty, Spring Data, Maven - Exception

Question

Próbuję zintegrować Spring Data w ramach naszego projektu Vaadin. Spróbowałem więc działa następujący przykładowy kod, który wykorzystuje te same technologie:

https://github.com/henrikerola/vaadin-spring-boot-todo

Jedyną rzeczą jest to, że zmieniłem dodałem molo ponieważ musimy użyć go do naszego projektu.

Niestety, po jetty:run Dostaję następujący wyjątek:

Exception in thread "main" java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype

Moje pom.xml wygląda tak:

<?xml version="1.0" encoding="UTF-8"?>... 
<modelVersion>4.0.0</modelVersion> 

<groupId>org.test</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.2.3.RELEASE</version> 
    <relativePath/> <!-- lookup parent from repository --> 
</parent> 

<properties> 
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
    <start-class>demo.DemoApplication</start-class> 
    <java.version>1.8</java.version> 
</properties> 

<dependencies> 
    <dependency> 
     <groupId>org.springframework.boot</groupId> 
     <artifactId>spring-boot-starter-data-jpa</artifactId> 
    </dependency> 
    <dependency> 
     <groupId>com.vaadin</groupId> 
     <artifactId>vaadin-spring-boot-starter</artifactId> 
     <version>1.0.0.beta2</version> 
    </dependency> 

    <dependency> 
     <groupId>com.h2database</groupId> 
     <artifactId>h2</artifactId> 
     <scope>runtime</scope> 
    </dependency> 
    <dependency> 
     <groupId>org.springframework.boot</groupId> 
     <artifactId>spring-boot-starter-test</artifactId> 
     <scope>test</scope> 
    </dependency> 
</dependencies> 

<dependencyManagement> 
    <dependencies> 
     <dependency> 
      <groupId>com.vaadin</groupId> 
      <artifactId>vaadin-bom</artifactId> 
      <version>7.4.2</version> 
      <type>pom</type> 
      <scope>import</scope> 
     </dependency> 
    </dependencies> 
</dependencyManagement> 

<build> 
    <plugins> 
     <plugin> 
      <groupId>org.springframework.boot</groupId> 
      <artifactId>spring-boot-maven-plugin</artifactId> 
     </plugin> 
     <plugin> 
      <groupId>org.eclipse.jetty</groupId> 
      <artifactId>jetty-maven-plugin</artifactId> 
      <version>9.2.10.v20150310</version> 
     </plugin> 
    </plugins> 
</build> 

Answer 1

nie mieli szansę wykopać rzeczywisty powód tego, ale podejrzewam, że kwestia classpath między jetty & tomcat który jest preferowany przez wiosenny but.

1. Tak czy inaczej, jeśli masz zamiar dalej za pomocą sprężyny-boot, która jest chyba najłatwiejszy The spring-boot documentation oferuje przykład zastępując tomcat z molo, i to jest proste jak dodanie następujących do pom:

<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-web</artifactId> 
    <exclusions> 
     <exclusion> 
      <groupId>org.springframework.boot</groupId> 
      <artifactId>spring-boot-starter-tomcat</artifactId> 
     </exclusion> 
    </exclusions> 
</dependency> 
<dependency> 
    <groupId>org.springframework.boot</groupId> 
    <artifactId>spring-boot-starter-jetty</artifactId> 
</dependency> 

Ponadto, zamiast uruchamiać mvn jetty-run, prawdopodobnie będziesz chciał uruchomić demo.DemoApplication, aby mógł poprawnie wykryć konfigurację sprężyny i zainicjować kontekst.

2. Jeśli planujesz unikać rozruchu wiosennego, usuń definicję nadrzędną, a także inne zależności i wtyczki rozruchowe. Pamiętaj też, aby ręcznie skonfigurować aplikację, aby zainicjować kontekst sprężyny podczas starcia.

Answer 2

Na co warto po dwóch latach: Komunikat o błędzie informuje, że org.eclipse.jetty.apache.jsp.JuliLog nie jest podklasą/realizacja org.apache.juli.logging.Log.

Dzieje się tak, jeśli istnieje wiele słoików zawierających tę samą klasę (org.apache.juli.logging.Log w tym przypadku ja przypuszczam) i wielu classloaders świadczące tej samej klasy (które są traktowane jako różne w instance-of i isAssignableFrom-checks).

Sprawdź słoiki pobrane dla wystąpienia org.apache.juli.logging.Log.class i sprawdź, skąd pochodzą. Po dostosowaniu tego w twoim pom, powinieneś być w stanie pozbyć się błędu.