jaxrs-api VS jsr311-VS api javax.ws.rs-api-VS-Trikot-core VS jaxrs-ri

Habe ich gegoogelt um ganz etwas bin immer noch verwirrt, was jede der oben genau meinst.

Hier ist mein Verständnis davon:

  • jaxrs-api : enthält eine einzige api. Keine Umsetzung. Aber wie unterscheidet es sich von JSR311
  • jsr311-api : JSR311 es ist eine Spezifikation, Anfrage. Das heißt, es soll ein Dokument. Warum ist es dann ein Glas?
  • javax.ws.rs-api: Ist es eine Umsetzung?
  • jersey-core(/jersey-client): Ist eine Implementierung von JSR311.

Ich heruntergeladen habe, jedes Glas und versuchte, Sie zu dekompilieren und sehen, was innen drin ist es, aber ich bin nur in der Lage zu finden, Schnittstellen, alle von Ihnen und nicht die Implementierung.

Ich bin mit diesen Fragen im Rahmen der doppelten Warnungen generiert maven-shade-plugin, und müssen das richtige Verständnis der oben, um herauszufinden, welche ausgeschlossen wird und warum.

InformationsquelleAutor Gadam | 2015-08-19
  1. 41

    Werde ich zunächst auf die Frage

    "JSR311 es ist eine Spezifikation, Anfrage. Das heißt, es soll ein Dokument. Warum ist es dann ein Glas?"

    Außer der letzten (jersey-core), alle diese Gläser sind "Spezifikation" Gläser. Die JAX-RS (sowie viele andere Java) Spezifikationen definieren die Verträge (oder Schnittstellen), die die Hersteller implementieren sollte das angegebene Verhalten für.

    Also im Grunde alle Klassen, angegeben in der Spezifikation sollte in der jar-Verträge. End-Benutzer der Gläser können Sie für die Verträge. aber es gibt keine Umsetzung. Sie müssen eine tatsächlich Umsetzung, um die Anwendung auszuführen, obwohl die spec-API-jar ist genug, um kompilieren eine komplette JAX-RS kompatiblen Anwendung.

    Zum Beispiel, wenn wir einer von denen Spezifikation API jars im classpath, können wir Autor eine ganze JAX-RS-Anwendung und kompilieren Sie es, aber um es zu starten, wenn wir nicht die eigentliche Umsetzung, die wir bereitstellen müssen, um einen server, der die eigentliche Implementierung der spec-version, z.B. JBoss oder Glassfish

    • jaxrs-api - Das ist RESTeasy ist Verpackung des spec. Es ist nicht die offizielle spec-Glas, aber es funktioniert, halten Sie die spec-Verträge. RESTeasy verwendet dieses Glas für die gesamte spec-Zeile, D. H. 1.x - Strom. Obwohl das Glas ändert Einbauten zu halten, um die verschiedenen JAX-RS Versionen.

    • jsr311-api - Dies ist die offizielle spec-Glas für die JAX-RS-1.x line.

    • javax.ws.rs-api - Dies ist die offizielle spec-Glas für die JAX-RS-2.x line.

    • jersey-core - Dies ist eine unvollständige Implementierung der spec. Der rest der Implementierung enthalten ist, in anderen Jersey-jars. Beachten Sie, dass in früheren Versionen von Jersey, Sie verpackten die JAX-RS Spezifikation APIs in diesem jar. Es war nicht bis später, dass Jersey begann mit der offiziellen spec-Gläser.

    • jaxrs-ri - - das ist das komplette Trikot 2.x Umsetzung, verpackt in eine jar. Das "ri" bedeutet Referenz-Implementierung, was Jersey ist: die JAX-RS Referenz-Implementierung. Wenn Sie nicht über ein dependency manager wie Maven, möchten Sie vielleicht, um Sie nur in diesem einzigen jar-statt alle einzeln Gläser, Jersey kommt mit.

    Andere Ressourcen

    Beachten Sie auch, dass, obwohl unterschiedliche Umsetzung der Einhaltung der Spezifikation, jede Anwendung hat seine eigenen extra-features. Um mehr zu erfahren, sollten Sie gehen Sie durch die Dokumentation der unterschiedlichen Implementierung. Die drei beliebtesten Implementierungen sind Jersey, RESTeasy, und CXF

    • Danke für die Antwort. So JSR311 ist die 'Spezifikation-Anfrage'; die entsprechende Spezifikation API' ist jsr311-api; Und diese und bilden Sie die JAX-RS-1.x-line. Nun, JSR339 ist die nächste 'Specification Request'; die 'Spezifikation API' ist 'javax.ws.rs-api " und Sie bilden JAX-RS-2.x-line. Bin ich richtig? Wenn ja, gibt es eine überschneidung zwischen JAX-RS 1.x und JAX-RS 2.x Zeilen? Würde Sie ein "maven shade duplizieren-Klasse-Warnung", wenn Sie zusammen verwendet werden? Aus jsr311-api, die javax.ws.rs-api, und jaxrs-api ist es am besten eine zu verwenden?
    • Das ist so ziemlich das wesentliche. Und ja sind sind überlappende Klassen. 2.x wirklich fügt nur auf 1.x. Ich kann nicht an nichts denken, das aus der Spitze von meinem Kopf, der entfernt wurde, in 2.x.
    • Ich meine, es hängt wirklich davon ab, Ihre Bedürfnisse. Ich persönlich bevorzuge die 2.x line, einfach, weil ich mit Jersey 2, die eine Reihe von Funktionen, aber wenn Sie wollen, vergleicht nur die standard-API, 2.x hat Filter und Abscheidern, async-Unterstützung, bean validation, und wahrscheinlich noch mehr Dinge, die ich kann nicht denken jetzt
    • Beachten Sie auch, dass, wenn Sie mit Maven, Sie nur selten eine explizite Abhängigkeit von der spec-Gläser. Was auch immer die Umsetzung, die Sie verwenden werden, ziehen Sie es in. Wenn Sie eine Bereitstellung auf einem EE-server, und Sie wan-zu-stick strikt an die spec (Aufenthalt portable), dann benötigen Sie lediglich das Java ee-api jar. Beachten Sie auch, dass wenn Sie ein 2.x Umsetzung und Sie haben ein 1.x jar im classpath, sind Sie wahrscheinlich zu bekommen NuSuchMethodErrors. Die wichtigsten API-Versionen nicht kompatibel sind.
    • Ich bin mit maven, und diese Gefäße gebracht wird, in transitiv durch meine direkte Abhängigkeiten. Ich bin nicht sicher, warum meine direkte Abhängigkeiten ziehen in der spec-Gläser, da Sie sagten, Sie brauchen nicht zu.. Naja das maven shade plugin Warnungen, die sagen, dass es die doppelt vorhandene Klassen aus diesen Gläsern. So versuchen, hinzufügen von Ausschlüssen auf so viele, wie ich Sie loswerden/Warnungen. Deine Antwort hilft mir. Danke.
    • Ihre app nicht ausgeführt werden, wenn Sie schließen Sie alle von Ihnen. Unabhängig von Durchführung Sie sind eigentlich mit, je nachdem, welche das Umsetzung zieht, das ist die, die Sie halten sollten.
    • "Es war nicht bis später, dass [Jersey], beginnend mit dem offiziellen spec-Gläsern." Es wäre sehr nützlich, wenn Sie die erste version number(s), dass nicht mehr die spec-APIs. Auf diese Weise könnte man sich lösen von alten Projekten durch verschieben der Abhängigkeit-version "gerade genug".

    InformationsquelleAutor Paul Samsotha
Schreibe einen Kommentar