Lookup JNDI vs Iniezione CDI
Sostituisci i fragili lookup JNDI basati su stringhe con l'iniezione CDI type-safe per le risorse gestite dal container.
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
}
}
}
Wiring type-safe
Gli errori di iniezione vengono rilevati al momento del deploy, non a runtime tramite lookup di stringhe.
Nessun boilerplate
Elimina la creazione di InitialContext, le stringhe JNDI e la gestione di NamingException.
Testabile
Le dipendenze sono campi iniettati, facilmente sostituibili con mock nei test unitari.
Ampiamente disponibile da Jakarta EE 8 / Java 11
Il pattern JNDI tradizionale ti costringe a usare nomi di risorse basati su stringhe, gestire NamingException e gestire un InitialContext. L'iniezione CDI con @Inject (o @Resource per le risorse container) lascia che il container crei automaticamente le dipendenze. I typo diventano errori di compilazione, e le classi sono più facili da testare perché le dipendenze possono essere iniettate direttamente.