Jersey a cessé de fonctionner avec InjectionManagerFactory non trouvé

Question

Je reçois l'erreur suivante en exécutant mon API Jersey dans Tomcat 8.5.11, ce qui provoque l'arrêt de mon API :

Statut HTTP 500 - Servlet.init() pour la servlet Jersey REST Service jeté exception

type Rapport d'exception

le message Servlet.init() pour la servlet Jersey REST Service a généré une exception.

description Le serveur a rencontré une erreur interne qui l'a empêché d'exécuter les tâches suivantes de répondre à cette demande.

exception

javax.servlet.ServletException : Servlet.init() pour la servlet Jersey REST Jersey REST a généré une exception org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.lang.Thread.run(Thread.java:745)

Cause profonde

java.lang.IllegalStateException : InjectionManagerFactory non trouvé. 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.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.lang.Thread.run(Thread.java:745)

L'application est construite avec les dépendances suivantes avec gradle :

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.+"
    ) }

Ces téléchargements jersey-common-2.26-b04.jar qui contient la classe manquante sous /org/glassfish/jersey/internal/inject/InjectionManagerFactory . Le fichier jar est déployé dans le dossier Tomcat sous WEB-INF/lib

Qu'est-ce qui peut bien se passer ici ? Le gradle script a fonctionné le mois dernier avec la même version de Tomcat.

Answer 1

Ajoutez cette dépendance :

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

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

Veillez à ne pas mélanger les versions de vos dépendances de Jersey. Cette réponse indique la version "2.28", mais utilisez la version de vos autres dépendances Jersey.

Answer 2

Jersey 2.26 et les versions plus récentes ne sont pas rétrocompatibles avec les versions plus anciennes. La raison de cette incompatibilité a été indiquée dans le notes de mise à jour :

Malheureusement, il a été nécessaire de faire des changements incompatibles avec le passé dans la 2.26. Concrètement, l'API client réactive propriétaire de Jersey a complètement disparu et ne peut plus être supportée. complètement disparue et ne peut plus être prise en charge - elle entre en conflit avec ce qui a été introduit dans JAX-RS 2.1 (c'est le prix à payer pour que Jersey soit "spec playground ").

Un autre changement important dans le code de Jersey est la tentative de rendre Jersey core indépendant de tout cadre d'injection spécifique. Comme vous le savez peut-être, Jersey 2.x est (était !) assez étroitement dépendant de HK2, ce qui parfois problèmes (en particulier lorsqu'il fonctionne avec d'autres conteneurs d'injection. Jersey définit désormais sa propre façade d'injection qui, lorsqu'il est mis en œuvre correctement, remplace toute injection interne de Jersey.

---

Pour l'instant, il faut utiliser les dépendances suivantes :

Maven

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

Gradle

compile 'org.glassfish.jersey.inject:jersey-hk2:2.26'

Answer 3

En voici la raison. A partir de la version 2.26 de Jersey, Jersey a supprimé HK2 en tant que dur dépendance. Il a créé un SPI comme façade pour le fournisseur d'injection de dépendances, sous la forme de l'élément InjectionManager y InjectionManagerFactory . Ainsi, pour que la Jersey fonctionne, nous devons avoir une implémentation de l'algorithme InjectionManagerFactory . Il existe deux implémentations de ce système, qui sont pour HK2 et CDI . La dépendance HK2 est la jersey-hk2 dont les autres parlent.

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

La dépendance du CDI est

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

Ce (jersey-cdi2-se) ne doit être utilisé que pour les environnements SE et non EE.

Jersey a fait ce changement pour permettre à d'autres de fournir leur propre cadre d'injection de dépendances. Ils n'ont pas l'intention d'implémenter d'autres systèmes d'injection de dépendances. InjectionManager bien que d'autres aient fait tentatives de mise en œuvre d'un pour Guice .

Answer 4

J'ai le même problème, après avoir rétrogradé à la version déployée en mars (2.26-b03) tout est revenu à la normale, j'espère que cela peut aider

Answer 5

Choisissez quel DI injecter dans le Jersey :

Printemps 4 :

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

Printemps 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>