Enterprise Fortgeschritten

Ersetze fragile JNDI-String-Lookups durch typsichere CDI-Injektion für vom Container verwaltete Ressourcen.

✕ Java EE
public class OrderService {
    private DataSource ds;

    public void init() throws NamingException {
        InitialContext ctx = new InitialContext();
        ds = (DataSource) ctx.lookup(
            "java:comp/env/jdbc/OrderDB");
    }

    public List<Order> findAll()
            throws SQLException {
        try (Connection con = ds.getConnection()) {
            // query orders
        }
    }
}
✓ Jakarta EE 8+
@ApplicationScoped
public class OrderService {
    @Inject
    @Resource(name = "jdbc/OrderDB")
    DataSource ds;

    public List<Order> findAll()
            throws SQLException {
        try (Connection con = ds.getConnection()) {
            // query orders
        }
    }
}
Problem mit diesem Code entdeckt? Sag uns Bescheid.
🔒

Typsichere Verdrahtung

Injektionsfehler werden zur Deployment-Zeit erkannt, nicht zur Laufzeit über String-Lookups.

🗑️

Kein Boilerplate

Eliminiert InitialContext-Erstellung, JNDI-Namens-Strings und NamingException-Behandlung.

🧪

Testbar

Abhängigkeiten sind injizierte Felder, die in Unit-Tests leicht durch Mocks ersetzt werden können.

Alter Ansatz
JNDI-Lookup
Moderner Ansatz
CDI @Inject
Seit JDK
11
Schwierigkeitsgrad
Fortgeschritten
JNDI-Lookup vs. CDI-Injektion
Verfügbar

Weitgehend verfügbar seit Jakarta EE 8 / Java 11

Das traditionelle JNDI-Muster zwingt zur Verwendung stringbasierter Ressourcennamen, zur Behandlung von NamingException und zur Verwaltung eines InitialContext. CDI-Injektion mit @Inject (oder @Resource für Container-Ressourcen) lässt den Container Abhängigkeiten automatisch verdrahten. Tippfehler werden zu Kompilierfehlern, und Klassen sind leichter zu testen, da Abhängigkeiten direkt injiziert werden können.

Teilen 𝕏 🦋 in