Búsqueda JNDI vs Inyección CDI
Reemplaza las frágiles búsquedas JNDI por cadenas con inyección CDI con seguridad de tipos para recursos gestionados por el contenedor.
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
}
}
}
Cableado con seguridad de tipos
Los errores de inyección se detectan en tiempo de despliegue, no en tiempo de ejecución mediante búsquedas por cadena.
Sin código repetitivo
Elimina la creación de InitialContext, cadenas de nombres JNDI y el manejo de NamingException.
Testeable
Las dependencias son campos inyectados, fácilmente reemplazables con mocks en pruebas unitarias.
Ampliamente disponible desde Jakarta EE 8 / Java 11
El patrón JNDI tradicional obliga a usar nombres de recursos basados en cadenas, manejar NamingException y gestionar un InitialContext. La inyección CDI con @Inject (o @Resource para recursos del contenedor) permite que el contenedor conecte las dependencias automáticamente. Los errores tipográficos se convierten en errores en tiempo de compilación, y las clases son más fáciles de probar porque las dependencias se pueden inyectar directamente.