Bereitgestellte Abhängigkeit und JBOSS EAP 7

Question

Ich verstehe, dass die bereitgestellten Abhängigkeiten vom Container "bereitgestellt" werden und die Anwendung diese JAR nicht generieren muss.

1) Also, ich benutze JBOSS EAP 7.0.0.GA und dies haben die folgenden jar in diesem Modul-Ordner: Hibernate-Core-5.0.9.Final-redhat-1.jar.

In meinem Projekt ich verwende die folgende Abhängigkeit:

<dependency> 
      <groupId>org.hibernate</groupId> 
      <artifactId>hibernate-core</artifactId> 
      <version>5.0.9.Final-redhat-1</version> 
     </dependency> 

Es funktioniert gut, ohne Fehler. Aber ich verstehe, dass ich den Bereich "PROVIDED" verwenden sollte, da dieses Glas vom Container bereitgestellt wird. Warum funktioniert es?

2) Ich habe ein anderes Beispiel. In Jboss Eap 7.0.0.GA habe ich folgendes jar: jboss-servlet-api_3.1_spec-1.0.0.Final-redhat-1.jar. Aber in meinem Projekt habe ich folgendes:

Es funktioniert gut, aber ich verstehe nicht warum. Für mich sollte die korrekte Abhängigkeit servlet-api_3.1_spec-1.0.0.Final-redhat-1 mit zur Verfügung gestellt werden. Warum funktioniert es auch?

Answer 1

Während der Erstellung wird Maven die Abhängigkeiten auflösen und die entsprechenden Pakete dem Compiler zur Verfügung stellen. Ihr Anwendungsserver kann beispielsweise JARs bereitstellen, die die Klassen und Schnittstellen in javax.servlet enthalten, aber diese Klassen sind für den Compiler nicht unbedingt nützlich, da sie nicht wissen, wo sie sich befinden. Indem Maven die Abhängigkeiten zur Verfügung gestellt werden, lässt Maven eigene Implementierungen dieser Abhängigkeiten finden, die nur zur Kompilierzeit verwendet werden.

Wenn Sie zur Laufzeit die Abhängigkeiten als provided markiert haben, verwendet Ihre Anwendung die vom Anwendungsserver bereitgestellten Versionen und nicht die Versionen, die Maven bekannt sind. Dies ist möglicherweise eine schlechte Sache, aber es funktioniert oft, weil der Compiler wirklich nur die Methodensignaturen kennen muss, nicht ihre Implementierungen. Die Methodensignaturen von Klassen, die von Spezifikationen gesteuert werden, z. B. in javax.servlet, ändern sich nur selten, sodass die Nichtübereinstimmung zwischen den Kompilierungszeit-JARs und Laufzeit-JARs möglicherweise nicht bemerkt wird. Im Gegensatz zu OSGi-kompatiblen JARs enthalten JARs, die für JEE erstellt wurden, keine Metadaten, die bestimmte kompatible Abhängigkeitsversionen angeben. JEE-Klassenlader verwenden das, was sie finden, zum Guten oder zum Schlechten.

Sie können jedoch erwischt werden - vor allem, wenn die Fehlanpassung erheblich ist. Probleme können zur Laufzeit sehr offensichtlich sein, z. B. Ausnahmen im Zusammenhang mit fehlenden Klassen oder Methoden, aber sie können subtil sein.

Es ist daher oft am besten, wenn möglich, dieselben Kompilierungszeitversionen von Abhängigkeiten wie die zur Laufzeit verfügbaren Versionen zu verwenden. Für EAP erinnere ich mich daran, dass Red Hat eine Maven-Stücklisten-Datei verteilt, die alle Versionen aller EAP-JARs für bestimmte EAP-Versionen angibt.