Solucionado (ver solução)
Solucionado
(ver solução)
7
respostas

Por que as classes anotadas com @Named não são interceptadas?

Olá,

Fiz um teste e percebi que as classes anotadas com @Named não são interceptadas, por quê?

E para que serve essa anotação?

Grato pela atenção.

7 respostas

Boa tarde Hugo,

Não sei te dizer o porque essa anotação não é interceptada, mas posso responder a outra questão.

Em um cenario, talvez não muito bom, de um sistema de cursos, onde cada curso tem seu conteudo

public interface Conteudo {
    void mostra(String descricao);
}

A annotation @Named ajuda a você especificar o tipo de Conteudo que você pretende fazer o @Inject quando você tem mais de um tipo daquela interface

@Named("cursoJava")
public class CursoJava implements Conteudo {
    public void mostra(String descricao) {
        //codigo
    }
}
@Named("cursoPhp")
public class CursoPhp implements Conteudo {
    public void mostra(String descricao) {
        //codigo
    }
}
@Inject
@Named("cursoJava")
private Conteudo conteudo;

Assim você consegue deixar o codigo mais flexivel, porém ainda é um pouco limitado, a cada vez que você precisar alterar o curso, precisa mudar em todos lugares que tiver nomeado ao fazer o @Inject.

Uma solução seria criar para curso, uma anotação especifica, para representar o mesmo.

Corrigindo("editando") um pouco o final, apesar de ficar limitado dessa forma, uma solução seria você criar uma anotação especifica para cada curso.

Oi Hugo,

a anotação @Named é de uma especificação que se chama CDI (Context e Dependency Injection). O CDI também faz parte do JavaEE e é bem parecido com EJB.

Ambos, EJB e CDI, fazem Inversão de Controle e Injeção de Dependências. De certa forma eles são concorrentes dentro do JavaEE. Ou seja, você poderia levantar JPA com CDI, administrar as transações com CDI etc.

O CDI entrou muito tarde no JavaEE, só versão 6, enquanto os EJBs existem desde iniciou. Isso pode ser um pouco confuso e até gerou muito polêmica entre os evangelistas dos EJBs.

Uma confusão vc está vendo agora, os interceptadores do EJB não funcionam com CDI, e os interceptadores do CDI não funcionam com EJB. Provável que no futuro essas diferenças são alinhadas dentro do JavaEE, mas por enquanto há essas diferenças, ok?

Abs, Nico

Oi Nico, sempre com ótimas respostas contextuais, legal, de forma que sejam parcialmente concorrentes, qual é a parte do EJB agora com a existencia do CDI?

O EJB ainda é muito usado em projetos, se sim, quais as principais razões?

Abraço!

solução!

Oi Douglas,

o EJB continua sendo utilizado, principalmente quando usa-se um servidor de aplicação.

A vantagem do EJB é que ele já "sabe" usar JPA ou gerenciar transação, é thread-safe por padrão etc etc. Com pouco esforço o desenvolvedor configura esse serviços fundamentais para qq aplicação.

O CDI, por sua vez, "só" sabe IoC com DI mas faz isso muito melhor do que EJB. Claro que podemos configurar JPA e transações com CDI tbm, mas quando estamos usando um servidor de aplicação já tem EJB para isso, ok?

A ideia do CDI é juntar/aproximar os frameworks da visão do EJB, por exemplo com JSF fica:

JSF <-> CDI <-> EJB

ou com JAX-RS:

JAX-RS <-> CDI <-> EJB

Então o CDI é um intermediário que ajudar na administração dos objetos e injeção dos serviços nos controladores, ok?

abs

Entendi agora a visão geral por traz do EJB com relação a outras specs, valeu Nico.

Entendi.

Obrigado! :D