Wie kann ich wissen, ob eine Maven-Abhängigkeit von einem Java EE-Webcontainer unterstützt wird?

Question

Hintergrund: Ich hatte ein Maven War Projekt migriert von WildFly 10.1.0.Final Java EE7 Full & Web-Distribution zu Payara Server 164 voll. Die Datei pom.xml wurde speziell auf die WildFly-Umgebung abgestimmt. Als Folge wurden einige der Abhängigkeiten des Bereichs <provided> nach der Migration problematisch, da Payara für sie keine korrekten Implementierungen hatte. Indem ich einige der Abhängigkeitsbereiche auf <compile> änderte, behob ich die Probleme. Aber es schien nicht sehr klug zu sein, jede der Abhängigkeiten zu testen, um zu sehen, ob man vom Container bereitgestellt wurde oder nicht.

Frage: Wie kann ich wissen, welche Abhängigkeiten von einem bestimmten Container unterstützt werden?

Zum Beispiel gibt es viele Versionen von Servlet API. Wie kann ich feststellen, ob Version 4.0.0-b01 von GlassFish 3.1.2.2 unterstützt wird?

Ich möchte in der Lage sein, es in einer angemessenen Weise zu tun. Z.B. Lesen aus den Dokumentationen, mit einem offiziellen Toolkit, etc. Übrigens habe ich in Payaras Dokumentation gesucht. Aber ich habe keine Liste der unterstützten Abhängigkeiten und Versionen gefunden.

Answer 1

In Ordnung, ich fand schließlich einen schöneren Weg, dies zu tun. Ich wurde von this answer inspiriert, obwohl es nicht direkt mit meiner Frage verbunden war.

Kurze Antwort: Gehe zu Java EE version history auf Wikipedia. Es gibt eine vollständige Liste der Implementierungen aller APIs, die jede Java EE-Containerversion implementiert.

Vollständige Antwort:

Java EE-Container sind Implementierungen von Java EE APIs. Dies bedeutet, dass Java EE-Projekte nicht alle Implementierungsbibliotheken der verwendeten Abhängigkeiten enthalten müssen. Stattdessen benötigen sie nur API-Bibliotheken wie servlet-api : 3.1.0. Wenn jedoch eine der API-Versionen "zu neu" oder "zu alt" ist und die nicht implementierten abstrakten Methoden aufgerufen werden, wird AbstractMethodError ausgelöst. Hier

ist ein Beispiel für diesen Fehler reproduzieren:

Auf einem Java EE 7 Behälter (Glassfish 4) mit jdk 1.8, verwenden servlet-api : 4.0.0-b02 als Servlet API (die mit Standardimplementierungen abstrakte Methoden enthält). Erstellen Sie einen ServletFilter, ohne die Methoden init und destroy zu implementieren. Stellen Sie den Server bereit und starten Sie ihn. Während des Starts erscheint ein AbstractMethodError.

Der Grund dafür ist, dass servlet-api : 4.0.0-b02 in Java EE 8 implementiert werden soll. Java EE 7 ist mit jdk 1.7 verknüpft, das die standardmäßige Schnittstellenmethode nicht unterstützt. Mit servlet-api : 3.1.0 (implementiert durch Java EE 7) müssen die Methoden und destroy im Projekt implementiert werden. Bei Verwendung von servlet-api : 4.0.0-b02 ist es jedoch möglich, sie nicht zu implementieren. Hier treten Probleme auf.

Zusammenfassend ist es in der Regel keine gute Idee, verschiedene Versionen zwischen Java EE APIs und ihren Implementierungen zu verwenden. Oracle bietet specifications für verschiedene Versionen von Java EE APIs als offizielle Einführung. Es sollte beim Erstellen von Projektabhängigkeiten überprüft werden.

Answer 2

Sie direkt zu verwenden ist keine sehr intelligente Idee.

Wenn Sie Web-Profil benötigen, verwenden Sie einfach:

<dependency> 
    <groupId>javax</groupId> 
    <artifactId>javaee-web-api</artifactId> 
    <version>7.0</version> 
    <scope>provided</scope> 
</dependency> 

Wenn Sie vollständige Profil benötigen, ist es leicht zu ändern:

<dependency> 
    <groupId>javax</groupId> 
    <artifactId>javaee-api</artifactId> 
    <version>7.0</version> 
    <scope>provided</scope> 
</dependency> 

Und du bist fertig. Alles, was von nun an im Projekt vorhanden ist und aus diesem Satz von Abhängigkeiten stammt, ist in den Anwendungsservern vorhanden.

Dies ist eigentlich der richtige Weg, es zu tun. Dein Weg ist falsch und wer dir gesagt hat, mit Java EE so zu arbeiten, verdient Strafe.