JNDI-Lookup vs. CDI-Injektion
Ersetze fragile JNDI-String-Lookups durch typsichere CDI-Injektion für vom Container verwaltete Ressourcen.
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
}
}
}
@ApplicationScoped
public class OrderService {
@Inject
@Resource(name = "jdbc/OrderDB")
DataSource ds;
public List<Order> findAll()
throws SQLException {
try (Connection con = ds.getConnection()) {
// query orders
}
}
}
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.
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.