JNDI, Deployment-Deskriptoren und Packaging

Neu bei JNDI? Dieses Kapitel setzt das Konzept voraus und behandelt es im Zusammenspiel mit Deployment-Deskriptoren und Packaging. Fuer eine langsamere, eigenstaendige Einfuehrung (was JNDI ueberhaupt ist, was bei einem Lookup wirklich passiert, java:comp/env erklaert) siehe zuerst 08-jndi-vertieft.md.

JNDI: das Namensverzeichnis der Java-EE-Welt

JNDI (Java Naming and Directory Interface) ist der Mechanismus, ueber den Java-EE-Komponenten Ressourcen (Datenquellen, JMS-Ziele, andere EJBs) per Namen statt per direkter Objektreferenz finden. Der Vorteil: der Code kennt nur einen logischen Namen (jdbc/novaris/policyDS), nicht die konkrete JDBC-URL, den Connection-Pool oder gar den physischen DB-Server - diese Bindung passiert ausschliesslich in der Serverkonfiguration (siehe src/main/liberty/config/server.xml). Dieselbe Anwendung laeuft dadurch unveraendert in Test- und Produktivumgebung, obwohl beide auf unterschiedliche physische Datenbanken zeigen.

Zwei Zugriffswege, siehe JndiLookupHelper-Javadoc fuer die volle Begruendung:

Dependency Injection (@Resource, @EJB, @PersistenceContext) - der bevorzugte Weg fuer alles, was der Container selbst verwaltet. Der Container kann die Referenz schon beim Deployment validieren, statt einen Fehler erst beim ersten tatsaechlichen Aufruf zu zeigen.
Programmatische Lookup (new InitialContext().lookup(...)) - fuer Code, der nicht vom Container instanziiert wird (Batch-Hauptprogramme, JSPs). JndiLookupHelper kapselt genau diesen Fall.

Portable JNDI-Namen (EJB 3.1+)

Seit EJB 3.1 spezifiziert der Standard ein portables globales JNDI-Namensschema fuer Business-Interfaces:

java:global[/<Anwendung>]/<Modul>/<Bean>[!<voll-qualifiziertes-Interface>]

Siehe JndiNames.POLICY_MANAGEMENT_LOCAL_EXAMPLE fuer ein konkretes Beispiel. Vor EJB 3.1 hatte jeder Anwendungsserver hierfuer sein eigenes, proprietaeres Schema - WebSphere, WebLogic und JBoss/WildFly vergaben grundverschiedene Namen fuer dieselbe Bean. Das portable Schema loest genau dieses Problem, wird aber in der Praxis selten direkt genutzt, weil Dependency Injection (@EJB) den expliziten Namen meist unnoetig macht.

Warum `ejb-jar.xml` trotz Annotationen noch existiert

Siehe die ausfuehrliche Begruendung im Kopf-Kommentar von novaris-policy-core/src/main/resources/META-INF/ejb-jar.xml selbst. Kurzfassung: XML kann annotierte Konfiguration ueberschreiben, ohne den Quellcode neu zu kompilieren - relevant fuer Interceptor-Bindungen (siehe docs/10-ejb-konzepte/05-interceptors.md) und Security-Rollen-Zuordnungen, die sich zwischen Umgebungen unterscheiden koennen. Bei einem Widerspruch zwischen Annotation und XML gewinnt die XML-Angabe.

Packaging: ejb-jar, WAR, EAR

Java-EE-Anwendungen werden in einer kleinen Hierarchie von Archivformaten verpackt:

ejb-jar (.jar) - ein EJB-Modul; enthaelt die Bean-Klassen, Interfaces, ejb-jar.xml, persistence.xml. novaris-policy-core ist inhaltlich ein solches Modul (aktuell noch als normales jar-Artefakt gebaut - die eigentliche ejb-jar-Verpackung mit vollstaendigem WebSphere-Deployment-Verhalten folgt in Phase 4, siehe unten).
war - ein Web-Modul (Servlets/JSP/JSF); kommt in Phase 4 mit novaris-policy-web dazu.
ear (Enterprise Archive) - buendelt mehrere Module (ein oder mehrere ejb-jars, wars, geteilte Bibliotheks-JARs) zu einer deploybaren Einheit mit gemeinsamem Klassenlader und einer application.xml, die festlegt, welche Module enthalten sind. WebSphere (traditional wie Liberty) deployt in aller Regel EARs, nicht einzelne JARs/WARs isoliert - das ist der Grund, warum EJB-Module und die Web-Module, die sie nutzen, meist im selben EAR landen: nur so koennen sie sich per @Local-Interfaces (schneller, einfacher Aufruf ohne Serialisierung) statt zwingend @Remote erreichen.

Status in diesem Projekt: Die tatsaechliche EAR-Verpackung (novaris-policy-ear, mit application.xml und dem Zusammenspiel mit novaris-policy-web) ist Teil von Phase 4 - siehe docs/00-ueberblick/systemlandschaft.md. Diese Phase ist bewusst die richtige Stelle dafuer, weil ein EAR erst dann einen echten Sinn ergibt, wenn es tatsaechlich mehr als ein Modul zu buendeln gibt (hier: das kommende Web-Modul plus dieses EJB-Modul).

Zusammenfassung

JNDI, Deployment-Deskriptoren und Packaging haengen eng zusammen: JNDI-Namen sind der "Klebstoff" zwischen Code und Serverkonfiguration; Deployment-Deskriptoren sind der Ort, an dem diese Bindung (und weitere Konfiguration) ausserhalb des Codes justiert werden kann; und die Archivhierarchie (ejb-jar/war/ear) bestimmt, welche Module ueberhaupt gemeinsam denselben JNDI-Namensraum und Klassenlader teilen.