Jersey funktioniert nicht mehr mit InjectionManagerFactory nicht gefunden

160

Beim Ausführen meiner Jersey-API in Tomcat 8.5.11 wird die folgende Fehlermeldung angezeigt, die dazu führt, dass meine API gestoppt wird:

HTTP-Status 500 - Servlet.init () für Servlet Jersey REST Service hat eine Ausnahme ausgelöst

Geben Sie Ausnahmebericht ein

Nachricht Servlet.init () für Servlet Jersey REST Service hat eine Ausnahme ausgelöst

Beschreibung Der Server hat einen internen Fehler festgestellt, der die Erfüllung dieser Anforderung verhindert hat.

Ausnahme

javax.servlet.ServletException: Servlet.init () für Servlet Jersey REST Service hat die Ausnahme org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:474) org.apache.catalina.valves.ErrorReportValve.invoke (Error. java: 79) org.apache.catalina.valves.AbstractAccessLogValve.invoke (AbstractAccessLogValve.java:624) org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:349) org.apache.coyote.http11.Htt. service (Http11Processor.java:783) org.apache.coyote.AbstractProcessorLight.process (AbstractProcessorLight.java:66) org.apache.coyote.AbstractProtocol $ ConnectionHandler.process (AbstractProtocol.java:798) org.apache.tomcat. net.NioEndpoint $ SocketProcessor.doRun (NioEndpoint.java:1434) org.apache.tomcat.util.net.SocketProcessorBase.Führen Sie (SocketProcessorBase.java:49) aus. java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:6t) org.ut. threads.TaskThread $ WrappingRunnable.run (TaskThread.java:61) java.lang.Thread.run (Thread.java:745)

Ursache

java.lang.IllegalStateException: InjectionManagerFactory nicht gefunden. org.glassfish.jersey.internal.inject.Injections.lookupInjectionManagerFactory (Injections.java:97) org.glassfish.jersey.internal.inject.Injections.createInjectionManager (Injections.java:89) org.glassfish.jersey.server.ApplicationHandler. (ApplicationHandler.java:282) org.glassfish.jersey.servlet.WebComponent. (WebComponent.java:335) org.glassfish.jersey.servlet.ServletContainer.init (ServletContainer.java:178) org.glassfish.jersey.servlet. ServletContainer.init (ServletContainer.java:370) javax.servlet.GenericServlet.init (GenericServlet.java:158) org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:474) org.apache.catalina. ErrorReportValve.invoke (ErrorReportValve.java:79) org.apache.catalina.valves.

Die Anwendung wird mit den folgenden Abhängigkeiten mit gradle erstellt:

dependencies {
    compile (
        // REST
        "org.glassfish.jersey.containers:jersey-container-servlet:2.+",
        "javax.servlet:javax.servlet-api:4.+",
        // REST Token
        "org.bitbucket.b_c:jose4j:0.+",
        // MongoDB
        "org.hibernate.ogm:hibernate-ogm-bom:5.+",
        "org.hibernate.ogm:hibernate-ogm-infinispan:5.+",
        "org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.+",
        "org.jboss.spec.javax.transaction:jboss-transaction-api_1.2_spec:1.+",
        "org.jboss.narayana.jta:narayana-jta:5.+",
        "org.jboss:jboss-transaction-spi:7.+",
        "log4j:log4j:1.+",
        "org.hibernate.ogm:hibernate-ogm-mongodb:5.+",
        "org.bouncycastle:bcprov-jdk15on:1.+"
    ) }

Dieser Download jersey-common-2.26-b04.jarenthält die fehlende Klasse unter /org/glassfish/jersey/internal/inject/InjectionManagerFactory. Die JAR-Datei wird im Tomcat-Ordner unter bereitgestelltWEB-INF/lib

Was kann hier falsch sein? Das Gradle-Skript hat in den letzten Monaten mit derselben Tomcat-Version funktioniert.

java  tomcat  gradle  jersey-2.0 
— Gregor
quelle
1
Ich sehe, es gab eine neue Version von Trikot am 19/05 - überprüfen Sie, ob dies das Problem ist, ich habe das gleiche Problem derzeit
— Roman Kesler
— Roman Kesler
Dieses Tutorial hat mir geholfen, dieses Problem zu beheben. Crunchify.com/…
— JesseBoyd

Antworten:

315

Fügen Sie diese Abhängigkeit hinzu:

<dependency>
    <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-hk2</artifactId>
    <version>2.28</version>
</dependency>

vgl. https://stackoverflow.com/a/44536542/1070215

Stellen Sie sicher, dass Sie Ihre Jersey-Abhängigkeitsversionen nicht mischen. Diese Antwort lautet Version "2.28", verwenden Sie jedoch die Version Ihrer anderen Jersey-Abhängigkeitsversionen.

— cthiebaud
quelle
2
Arbeitete für mich mit 2.26 Release-Version. Ich wollte keine Beta-Versionen im Produktionscode verwenden.
— Saganas
2
Danke, das ist die richtige Antwort. Arbeitet mit
— 2.26
1
Siehe auch zur Erklärung.
— Paul Samsotha
2
Das war es für mich - Version 2.28.
— Absmiths
Was für mich bizarr war, war, dass es funktionierte und dann nicht mehr funktionierte, bis ich die oben genannte Aufnahme gemäß diesem Beitrag vorgenommen habe. Trotzdem danke. Meine Kernversion war 2.30 und meine Injektionsversion wie oben, dh 2.28.
— Beezer
127

Jersey 2.26 und höher sind nicht abwärtskompatibel mit älteren Versionen. Der Grund dafür wurde in den Versionshinweisen angegeben :

Leider mussten in 2.26 rückwärts inkompatible Änderungen vorgenommen werden. Konkret ist die Jersey-eigene reaktive Client-API vollständig verschwunden und kann nicht mehr unterstützt werden - sie steht im Widerspruch zu dem, was in JAX-RS 2.1 eingeführt wurde (das ist der Preis für Jersey als "spezifizierter Spielplatz").

Eine weitere größere Änderung im Jersey-Code ist der Versuch, den Jersey-Kern von einem bestimmten Injektionsgerüst unabhängig zu machen. Wie Sie jetzt vielleicht sehen, ist (war!) Jersey 2.x ziemlich stark von HK2 abhängig, was manchmal zu Problemen führt (insbesondere beim Betrieb mit anderen Injektionsbehältern. Jersey definiert jetzt seine eigene Injektionsfassade , die bei ordnungsgemäßer Implementierung alle ersetzt interne Jersey-Injektion.

Für den Moment sollte man folgende Abhängigkeiten verwenden:

Maven

<dependency>
    <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-hk2</artifactId>
    <version>2.26</version>
</dependency>

Gradle

compile 'org.glassfish.jersey.core:jersey-common:2.26'
compile 'org.glassfish.jersey.inject:jersey-hk2:2.26'
— wypieprz
quelle
— Grigory Kislin
11
Seufz ... warum sollte Jersey die Version nicht auf 3.0 bringen, wenn sie eine bahnbrechende Änderung
— vornehmen
1
@trevorism Ich habe das Gefühl, dass sie die Hauptversion mit der JAX-RS-Hauptversion synchron halten wollen. Das ist das einzige, was für mich Sinn macht.
— Paul Samsotha
Auch Trikot-Common ist keine Voraussetzung ( manuell hinzufügen). Dies sollte bereits vom Jersey-Server übernommen werden, der vom Jersey-Container-Servlet-Core oder einer anderen von Ihnen verwendeten "Haupt" -Trikot-Abhängigkeit abgerufen werden sollte. Die einzige erforderliche Abhängigkeit, um den fraglichen Fehler zu beseitigen, ist das Trikot-hk2 (oder das Trikot-cdi2-se, wie hier erwähnt ).
— Paul Samsotha
@LuisF, es wäre richtig, wenn es nicht die unnötige Abhängigkeit von Trikots enthalten würde. Dies ist bereits eine transitive Abhängigkeit.
— Paul Samsotha
47

Hier ist der Grund. Ab Jersey 2.26 entfernte Jersey HK2 als harte Abhängigkeit. Es wurde ein SPI als Fassade für den Abhängigkeitsinjektionsanbieter in Form des InjectionManagerund erstellt InjectionManagerFactory. Damit Jersey laufen kann, müssen wir eine Implementierung des haben InjectionManagerFactory. Es gibt zwei Implementierungen davon, die für HK2 und CDI sind . Die HK2-Abhängigkeit ist die jersey-hk2, über die die anderen sprechen.

<dependency>
    <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-hk2</artifactId>
    <version>2.26</version>
</dependency>

Die CDI-Abhängigkeit ist 

<dependency>
    <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-cdi2-se</artifactId>
    <version>2.26</version>
</dependency>

Dies (jersey-cdi2-se) sollte nur für SE-Umgebungen und nicht für EE-Umgebungen verwendet werden.

Jersey hat diese Änderung vorgenommen, damit andere ihr eigenes Abhängigkeitsinjektions-Framework bereitstellen können. Sie haben keine Pläne, andere InjectionManagers zu implementieren , obwohl andere versucht haben, eines für Guice zu implementieren .

— Paul Samsotha
quelle
1
Beachten Sie, dass für die Verwendung von CDI (jersey-cdi2-se) eine bean.xml-Konfiguration in META-INF erforderlich ist. Andernfalls wird die folgende Ausnahme ausgelöst: java.lang.IllegalStateException: WELD-ENV-000016: Fehlende beans.xml-Datei in META-INF
— Marco Montel
Diese Antwort hat mir bei so vielen Inkonsistenzen geholfen, dass +1 zur Klärung von jersey-cdi2-se nur für SE verwendet werden sollte
— Daniel Arechiga
11

Wählen Sie aus, welcher DI in Jersey injiziert werden soll:

Frühling 4:

<dependency>
  <groupId>org.glassfish.jersey.ext</groupId>
  <artifactId>jersey-spring4</artifactId>
</dependency>

Frühling 3:

<dependency>
  <groupId>org.glassfish.jersey.ext</groupId>
  <artifactId>jersey-spring3</artifactId>
</dependency>

HK2:

<dependency>
    <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-hk2</artifactId>
</dependency>
— broc.seib
quelle
2
Es ist nicht so leicht. Sie können HK2 nicht einfach für Spring ausschalten. Bei der jersey-springIntegration wird weiterhin eine HK2-Brücke unter der Haube verwendet, damit sie funktioniert.
— Paul Samsotha
2

Ich konnte es nur lösen über:

org.glassfish.jersey.core Trikot-Server $ {Trikot-2-Version} 

<dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <artifactId>jersey-container-servlet</artifactId>
    <version>${jersey-2-version}</version>
</dependency>

<dependency>
    <groupId>org.glassfish.jersey.inject</groupId>
    <artifactId>jersey-hk2</artifactId>
    <version>${jersey-2-version}</version>
</dependency>

<!-- https://mvnrepository.com/artifact/org.glassfish.jersey.core/jersey-common -->
<dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-common</artifactId>
    <version>${jersey-2-version}</version>
</dependency>

<dependency>
    <groupId>org.glassfish.jersey.containers</groupId>
    <artifactId>jersey-container-servlet-core</artifactId>
    <version>${jersey-2-version}</version>
</dependency>

Also nur, wenn ich hinzugefügt hätte jersey-container-servletund jersey-hk2es ohne Fehler laufen würde

— Johannes Jander
quelle
0

Soweit ich sehen kann, haben sich die Abhängigkeiten zwischen 2.26-b03 und 2.26-b04 geändert (HK2 wurde von compile nach testCompile verschoben). Möglicherweise haben sich die Trikotabhängigkeiten geändert, die noch nicht abgeschlossen wurden (oder zu führen) ein Käfer).

Im Moment besteht die einfache Lösung jedoch darin, sich an eine ältere Version zu halten :-)

— Nikolaus Krismer
quelle
-2

Hier ist die neue Abhängigkeit (August 2017)

    <!-- https://mvnrepository.com/artifact/org.glassfish.jersey.core/jersey-common -->
<dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-common</artifactId>
    <version>2.0-m03</version>
</dependency>
— Ricardo Rossini
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.