Enterprise Intermediário

Substitua lookups JNDI frágeis baseados em strings por injeção CDI type-safe para recursos gerenciados pelo container.

✕ 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
        }
    }
}
Viu um problema com este código? Nos avise.
🔒

Conexão type-safe

Erros de injeção são detectados no deploy, não em tempo de execução via lookups de strings.

🗑️

Sem boilerplate

Elimina a criação de InitialContext, strings de nomes JNDI e tratamento de NamingException.

🧪

Testável

Dependências são campos injetados, facilmente substituíveis por mocks em testes unitários.

Abordagem Antiga
JNDI Lookup
Abordagem Moderna
CDI @Inject
Desde o JDK
11
Dificuldade
Intermediário
JNDI Lookup vs Injeção CDI
Disponível

Amplamente disponível desde o Jakarta EE 8 / Java 11

O padrão tradicional JNDI obriga o uso de nomes de recursos baseados em strings, tratamento de NamingException e gerenciamento de um InitialContext. A injeção CDI com @Inject (ou @Resource para recursos do container) permite que o container conecte as dependências automaticamente. Erros de digitação se tornam erros em tempo de compilação, e as classes ficam mais fáceis de testar porque as dependências podem ser injetadas diretamente.

Compartilhar 𝕏 🦋 in