Jersey przestał działać z nie znaleziono InjectionManagerFactory


161

Otrzymuję poniższy błąd podczas uruchamiania interfejsu Jersey API w Tomcat 8.5.11, który powoduje zatrzymanie mojego interfejsu API:

Status HTTP 500 - Servlet.init () dla serwletu Jersey Usługa REST zgłosiła wyjątek

wpisz Raport wyjątków

komunikat Servlet.init () dla serwletu Jersey Usługa REST zgłosił wyjątek

opis Serwer napotkał błąd wewnętrzny, który uniemożliwił mu realizację tego żądania.

wyjątek

javax.servlet.ServletException: Servlet.init () dla serwletu Usługa REST na Jersey zgłosiła wyjątek org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:474) org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.invoke (ErrorReportValve.invoke. 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.apil.tomcat.ut 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.aputache.tomcat. Threads.TaskThread $ WrappingRunnable.run (TaskThread.java:61) java.lang.Thread.run (Thread.java:745)

pierwotna przyczyna

java.lang.IllegalStateException: nie znaleziono InjectionManagerFactory. 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.apacheves.catalina. ErrorReportValve.invoke (ErrorReportValve.java:79) org.apache.catalina.valves.

Aplikacja jest zbudowana z następującymi zależnościami w 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.+"
    ) }

Ten plik do pobrania jersey-common-2.26-b04.jarzawiera brakującą klasę w ramach /org/glassfish/jersey/internal/inject/InjectionManagerFactory. Plik jar jest wdrażany w folderze Tomcat wWEB-INF/lib

Co tu może być nie tak? Skrypt gradle działał przez ostatnie kilka miesięcy z tą samą wersją Tomcata.


1
widzę, że 19.05 pojawiła się nowa wersja koszulki - sprawdź czy to jest problem, mam ten sam problem w tej chwili
Roman Kesler


Ten samouczek pomógł mi rozwiązać ten problem crunchify.com/…
JesseBoyd

Odpowiedzi:


316

Dodaj tę zależność:

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

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

Upewnij się, że nie mieszasz swoich wersji zależności Jersey. Ta odpowiedź mówi o wersji "2.28", ale użyj dowolnej wersji, którą posiadasz w innych wersjach zależności Jersey.


2
Pracowałem dla mnie z wydaniem 2.26. Nie chciałem używać wersji beta w kodzie produkcyjnym.
saganas

2
Dziękuję, to jest poprawna odpowiedź. Działa z 2.26
mario

1

2
To było to dla mnie - wersja 2.28.
absmiths

Dziwne było dla mnie to, że działało, a potem przestało działać, AŻ nie zrobiłem powyższego włączenia zgodnie z tym postem. W każdym razie dziękuję. Moja podstawowa wersja to 2.30, a moja wersja iniekcyjna jak powyżej, czyli 2.28.
Beezer

127

Jersey 2.26 i nowsze nie są wstecznie kompatybilne ze starszymi wersjami. Powód tego został podany w informacjach o wydaniu :

Niestety w 2.26 zaistniała potrzeba wprowadzenia wstecznej niezgodności zmian. Konkretnie, opatentowane przez koszulkę, reaktywne API klienta całkowicie zniknęło i nie może być dłużej obsługiwane - jest to sprzeczne z tym, co zostało wprowadzone w JAX-RS 2.1 (taka jest cena za to, że Jersey jest „wyspecjalizowanym placem zabaw…”).

Kolejną większą zmianą w kodzie Jersey jest próba uniezależnienia rdzenia Jersey od jakiegokolwiek konkretnego frameworka wstrzykiwania. Jak możesz teraz, Jersey 2.x jest (był!) Dość ściśle zależny od HK2, co czasami powoduje problemy (szczególnie podczas pracy z innymi pojemnikami wtryskowymi. Jersey definiuje teraz swoją własną fasadę wtrysku , która po prawidłowym wdrożeniu zastępuje wszystkie wewnętrzny zastrzyk Jersey.


Na razie należy użyć następujących zależności:

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'


11
Ech ... dlaczego nie Jersey wpadać w wersji 3,0, jeśli są one dokonywania zmian zerwaniu ..
trevorism

1
@trevorism Mam wrażenie, że chcą zsynchronizować wersję główną z wersją główną JAX-RS. To jedyna rzecz, która ma dla mnie sens.
Paul Samsotha,

Również typowa koszulka nie jest wymagana (do ręcznego dodania). Powinno to już zostać pobrane przez jersey-server, który powinien zostać pobrany przez jersey-container-servlet-core lub jakąkolwiek inną "główną" zależność od koszulki, której używasz. Jedyną wymaganą zależnością, aby pozbyć się omawianego błędu, jest jersey-hk2 (lub jersey-cdi2-se, jak wspomniano tutaj ).
Paul Samsotha,

@LuisF, Byłoby poprawne, gdyby nie zawierało niepotrzebnej wspólnej zależności od koszulki. To już jest zależność przechodnia.
Paul Samsotha

47

Oto powód. Począwszy od Jersey 2.26, Jersey usunął HK2 jako trudną zależność. Stworzył SPI jako fasadę dla dostawcy wstrzykiwania zależności, w postaci InjectionManageri InjectionManagerFactory. Aby Jersey działał, musimy mieć implementację InjectionManagerFactory. Istnieją dwie implementacje tego, które są dla HK2 i CDI . jersey-hk2Inni mówią o zależności od HK2 .

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

Zależność CDI to

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

To (jersey-cdi2-se) powinno być używane tylko w środowiskach SE, a nie w środowiskach EE.

Jersey wprowadził tę zmianę, aby umożliwić innym udostępnianie własnej struktury wstrzykiwania zależności. Nie mają żadnych planów wdrożenia innych InjectionManager, chociaż inni próbowali zaimplementować taki dla Guice .


1
Zauważ, że użycie CDI (jersey-cdi2-se) wymaga konfiguracji bean.xml w META-INF. W przeciwnym razie zostanie zgłoszony następujący wyjątek: java.lang.IllegalStateException: WELD-ENV-000016: Brak pliku beans.xml w META-INF
Marco Montel

Ta odpowiedź pomogła mi z tak wieloma niespójnościami, +1 dla wyjaśnienia jersey-cdi2-se powinno być używane tylko dla SE
Daniel Arechiga

11

Wybierz DI, aby wstrzyknąć rzeczy do Jersey:

Wiosna 4:

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

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

2
To nie jest takie proste. Nie możesz po prostu zmienić HK2 na wiosnę. jersey-springIntegracja nadal używa most HK2 pod maską, aby to działało.
Paul Samsotha,

2

Jedyny sposób, w jaki mogłem go rozwiązać, to:

org.glassfish.jersey.core jersey-server $ {jersey-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>

Czyli tylko gdybym dodał jersey-container-servleti jersey-hk2czy działałby bez błędów


0

O ile widzę, zależności zmieniły się między 2.26-b03 a 2.26-b04 (HK2 został przeniesiony z kompilacji do testCompile) ... może nastąpić pewna zmiana w zależnościach koszulki, która nie została jeszcze ukończona (lub która prowadzi do błąd).

Jednak w tej chwili prostym rozwiązaniem jest trzymanie się starszej wersji :-)


-2

Oto nowa zależność (sierpień 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>
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.