124 votes

Jersey a cessé de fonctionner avec InjectionManagerFactory introuvable

Je suis la réception d'erreur ci-dessous lors de l'exécution de mon Maillot de l'API dans Tomcat 8.5.11 qui est à l'origine de mon API pour arrêter:

D'État HTTP 500 - Servlet.init() de la servlet Maillot de Service REST jeté exception

type de rapport d'Exception

message de Servlet.init() de la servlet Maillot RESTE Service a généré une exception

description Le serveur a rencontré une erreur interne qui l'a empêché de répondre à cette demande.

exception

javax.servlet.ServletException: Servlet.init() de la servlet Maillot de REPOS Service a généré une exception org.apache.catalina.authentificateur.AuthenticatorBase.invoke(AuthenticatorBase.java:474) org.apache.catalina.les vannes.ErrorReportValve.invoke(ErrorReportValve.java:79) org.apache.catalina.les vannes.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624) org.apache.catalina.connecteur.CoyoteAdapter.service(CoyoteAdapter.java:349) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783) org.apache.coyote.AbstractProcessorLight.processus(AbstractProcessorLight.java:66) org.apache.coyote.AbstractProtocol$ConnectionHandler.processus(AbstractProtocol.java:798) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434) org.apache.tomcat.util.net.SocketProcessorBase.exécuter(SocketProcessorBase.java:49) java.util.de façon concomitante.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java.util.de façon concomitante.ThreadPoolExecutor$Travailleur.exécuter(ThreadPoolExecutor.java:617) org.apache.tomcat.util.les threads.TaskThread$WrappingRunnable.exécuter(TaskThread.java:61) java.lang.Fil de discussion.exécution(Thread.java:745)

cause

java.lang.IllegalStateException: InjectionManagerFactory pas trouvé. org.glassfish.jersey.interne.injecter.Les Injections.lookupInjectionManagerFactory(Injections.java:97) org.glassfish.jersey.interne.injecter.Les Injections.createInjectionManager(Injections.java:89) org.glassfish.jersey.serveur.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.authentificateur.AuthenticatorBase.invoke(AuthenticatorBase.java:474) org.apache.catalina.les vannes.ErrorReportValve.invoke(ErrorReportValve.java:79) org.apache.catalina.les vannes.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624) org.apache.catalina.connecteur.CoyoteAdapter.service(CoyoteAdapter.java:349) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783) org.apache.coyote.AbstractProcessorLight.processus(AbstractProcessorLight.java:66) org.apache.coyote.AbstractProtocol$ConnectionHandler.processus(AbstractProtocol.java:798) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434) org.apache.tomcat.util.net.SocketProcessorBase.exécuter(SocketProcessorBase.java:49) java.util.de façon concomitante.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java.util.de façon concomitante.ThreadPoolExecutor$Travailleur.exécuter(ThreadPoolExecutor.java:617) org.apache.tomcat.util.les threads.TaskThread$WrappingRunnable.exécuter(TaskThread.java:61) java.lang.Fil de discussion.exécution(Thread.java:745)

La demande est à construire 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.+"
    ) }

Cette téléchargements jersey-common-2.26-b04.jar qui contient le manque de classe en vertu de l' /org/glassfish/jersey/internal/inject/InjectionManagerFactory. Le fichier jar est déployé dans le Tomcat sous-dossier WEB-INF/lib

Quel est le problème ici? Le gradle script a travaillé depuis quelques mois avec la même version de Tomcat.

240voto

cthiebaud Points 175

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

113voto

wypieprz Points 1063

Maillot 2.26 et les nouveaux ne sont pas compatibles avec les anciennes versions. La raison derrière ce qui a été mentionné dans les notes de publication:

Malheureusement, il y avait un besoin de faire des changements incompatibles dans 2.26. Concrètement jersey-propriétaire réactif de l'API client est complètement disparu et ne sera plus pris en charge - il est en conflit avec ce qui a été introduit dans de JAX-RS 2.1 (c'est le prix pour le Jersey étant "spec aire de jeux..").

Un autre grand changement en Jersey de code est de tenter de faire en Jersey de base indépendant de toute infrastructure d'injection. Comme vous devez le savoir, Maillot 2.x est (était!) assez étroitement lié à la HK2, qui parfois les causes des problèmes (esp. lors de l'exécution sur les autres d'injection de conteneurs. Jersey maintenant, définit ses propres injection de façade, dont la mise en œuvre correctement, remplace tous les internes Jersey injection.


Comme pour l'instant, on devrait utiliser les dépendances suivantes:

Maven

<dependency>
    <groupId>org.glassfish.jersey.core</groupId>
    <artifactId>jersey-common</artifactId>
    <version>2.26</version>
</dependency>

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

34voto

peeskillet Points 32287

Voici la raison. À partir de Jersey 2.26, Maillot retiré HK2 comme un dur de dépendance. Il a créé un SPI comme une façade pour l'injection de dépendance fournisseur, dans la forme de l' InjectionManager et InjectionManagerFactory. Donc pour le Jersey à terme, nous avons besoin de la mise en œuvre de l' InjectionManagerFactory. Il existe deux implémentations de cette, qui sont pour HK2 et CDI. Le HK2 dépendance est l' jersey-hk2 d'autres sont en train de parler.

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

Le CDI dépendance est

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

Ce (jersey-cdi2-se) doit être utilisé uniquement pour SE environnements et pas EE environnements.

Jersey fait ce changement pour permettre aux autres de donner leur propre infrastructure d'injection de dépendance. Ils n'ont pas de plans de mise en œuvre de toute autre InjectionManagers, si d'autres ont fait des tentatives de mise en œuvre de l'un de Guice.

26voto

Roman Kesler Points 638

J'ai le même problème, après avoir rétrogradé la version déployée en mars (2.26-b03), tout est rentré dans l'ordre, j'espère que cela aidera

10voto

broc.seib Points 1767

Choisissez quelle DI injecter dans 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>
 

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: