Java RestFull WebService: JAX-RS-Implementierung mit Jersey 2.3.1-Bibliotheken

Ich versuche, eine einfache “Hallo Welt” -Anwendung Jersey 2.3.1 REST-Service auf JBoss jboss-eap-6.1 AS zu betreiben. In web.xml habe ich die restEasy-Bibliothek deaktiviert. Während der Bereitstellung erhalte ich den Fehler:

JBWEB000289: Servlet com.sun.jersey.samples.helloworld.resources.MyApplication hat load () – Ausnahme ausgetriggers: java.lang.NoSuchMethodError: javax.ws.rs.core.Application.getProperties () Ljava / util / Map;

In POM setze ich diese Abhängigkeiten:

 org.glassfish.jersey.core jersey-server 2.3.1   org.glassfish.jersey.containers jersey-container-servlet-core 2.3.1   javax.ws.rs javax.ws.rs-api 2.0  

Dies ist meine web.xml mit deaktivierten restEasy-Tags:

    com.sun.jersey.samples.helloworld.resources.MyApplication org.glassfish.jersey.servlet.ServletContainer  javax.ws.rs.Application com.sun.jersey.samples.helloworld.resources.MyApplication  1   resteasy.scan false   resteasy.scan.providers false   resteasy.scan.resources false   com.sun.jersey.samples.helloworld.resources.MyApplication /*   

Und meine Ressourcen-Konfiguration Java-class:

 package com.sun.jersey.samples.helloworld.resources; import org.glassfish.jersey.server.ResourceConfig; public class MyApplication extends ResourceConfig { public MyApplication() { packages("com.sun.jersey.samples.helloworld.resources"); //super(HelloWorldResource.class); } } 

Jemand hat eine Idee, es zu lösen? Danke im Voraus, Roberto

NoSuchMethodError bedeutet normalerweise, dass Sie zwei verschiedene Versionen der class in Ihrem classnpfad haben. Da die javax.ws.rs.core.Application class die Methode getProperties() in ihrer JAX-RS 2-Version, aber nicht in JAX-RS 1.x hat, würde ich annehmen, dass Sie irgendwie das alte 1.x kombinieren Jersey (oder alte REST api) mit dem aktuellen (2.3.1).

Auch das Paket, in dem du com.sun.jersey ( com.sun.jersey – das ‘alte’ Jersey-Paket) zeigt ein wenig in diese Richtung (obwohl du deinen Code einfach nicht selbst in das Paket einbauen kannst), hast du offensichtlich mit dem Jersey angefangen 1.x Beispiel als Basis (es gibt auch Beispiele in Jersey 2, siehe helloworld-webapp auf Jersey GitHub).

Ist es möglich, dass restEasy (auch definitiv die javax.ws.rs.core.Application class enthaltend) nicht komplett ausgeschaltet ist und irgendwie auf die JAX-RS 1.x-Version javax.ws.rs.core.Application ?

Ich würde mit der Inspektion Ihrer Pom-Datei beginnen, den effektiven Pom betrachten (wenn Ihr Projektdeskriptor ein Elternteil hat) und sorgfältig prüfen, was auf Ihrem classnpfad ist – ich glaube, es gibt irgendwo eine 1.x-Version von javax.ws.rs-api . Versuchen Sie auch, alle kompilierten Sachen zu säubern und von Grund auf neu aufzubauen.

Apropos Abhängigkeiten: Wenn Ihre Liste erschöpfend ist (in Bezug auf Jersey), müssen Sie höchstwahrscheinlich die jersey-common (2.3.1) PackageScanner hinzufügen, da die ResourceConfig.packages() -Methode bereits während der Initialisierung den PackageScanner Konstruktor PackageScanner enthält den Aufruf von ReflectionHelper – und das ist kein Teil des Server-Jar mehr.

Hoffe das hilft.

Ich hatte in letzter Zeit dasselbe Problem. Ich dachte, teile meine Schritte für dich. Wie die anderen antworten, liegt das Problem hauptsächlich daran, dass Sie zwei verschiedene Versionen derselben class in Ihrem classnpfad haben. Also, wenn Sie Maven Abhängigkeiten in Ihrem Pom hinzufügen, seien Sie vorsichtig.

Diese Art von Problemen nennt man normalerweise Jar Hell . Sie können die API von jhades verwenden, um zu untersuchen, ob sich die classn überschneiden. Hier sind die einfachen Schritte, denen ich gefolgt bin.

Fügen Sie jhades Abhängigkeit in Ihren Pom hinzu.

  org.jhades jhades 1.0.4  

Zeigen Sie den Bericht an

Rufen Sie new JHades().overlappingJarsReport(); in Ihrer Hauptmethode wird es auf stdout ausgeben.

Beispielausgabe:

 file:/Users/justin/.m2/repository/javax/ws/rs/jsr311-api/1.1.1/jsr311-api-1.1.1.jar overlaps with file:/Users/justin/.m2/repository/javax/ws/rs/javax.ws.rs-api/2.0/javax.ws.rs-api-2.0.jar - total overlapping classes: 55 - same classloader ! This is an ERROR! 

Entfernen Sie eine der Überlappungsmappenabhängigkeiten in Ihrem Pom.

Sie können auch einen anderen Ansatz wie die Abhängigkeitsausschlüsse von Maven verwenden.

Quelle: Blogpost auf jhades

Hoffe, das wird jemandem helfen 🙂

Habe es gerade mit JBoss EAP 6.1.1 – Jersey 2.3.1 gemacht.

Die üblichen Dinge scheinen nicht zu funktionieren / sind alleine nicht genug:

  • Deaktivieren des Jaxrs-Subsystems in standalone.xml / domain.xml
  • oder, mit Ausnahme der jax-rs-Module in jboss-deployment-structure.xml

Außerdem müssen Sie das Laden der jax-rs 1.1 API komplett deaktivieren, indem Sie module.xml in jboss-eap-6.1 / modules / system / layers / base / javax / ws / rs / api / main / module.xml wie folgt modifizieren :

           

Bitte beachten Sie, dass dadurch die jax-rs-Implementierung von JBoss (RestEasy) auch für alle anderen Anwendungen deaktiviert wird (ebenso wie das Jaxrs-Subsystem in standalone / domain.xml deaktiviert wird).

Dies ist ein Konfliktproblem bei der Jersey-Version. Ich hatte das gleiche Problem. Hier ist, wie es getriggers ist:

  1. Sehen Sie Ihre Paketabhängigkeiten “mvn dependency: tree”

  2. Wenn eine Bibliotheksabhängigkeit von einer alten Jersey-Version abhängt, können Sie im dependency-Tag für diese Bibliothek in pom.xml einen Abschnitt für Ausschlüsse hinzufügen

Mit mvn dependency: tree (danke für den Vorschlag oben) konnte ich feststellen, dass der Täter (in meinem Fall) war: javax.ws.rs:jsr311-api:1.1 Das Entfernen dieser Abhängigkeit triggerse mein Problem.