Padrão de fábrica avastática com EJB3/JBoss

Question

Sou bastante novo em EJBS e servidores de aplicativos completos como o JBoss, tendo escrito e trabalhado com aplicativos Java independentes para fins especiais para a maior parte da minha carreira, com uso limitado de Java EE. Estou me perguntando sobre a melhor maneira de adaptar um padrão de design comumente usado ao EJB3 e JBoss: o padrão de fábrica estática. De fato, este é o Item #1 no livro Java de Joshua Bloch (2ª edição)

Atualmente, estou trabalhando com a seguinte fábrica:

public class CredentialsProcessorFactory {
    private static final Log log = LogFactory.getLog(CredentialsProcessorFactory.class);
    private static Map<CredentialsType, CredentialsProcessor> PROCESSORS = 
        new HashMap<CredentialsType, CredentialsProcessor>();

    static {
        PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
    }

    private CredentialsProcessorFactory() {}

    public static CredentialsProcessor getProcessor(CredentialsType type) {
       CredentialsProcessor p = PROCESSORS.get(type);
       if(p == null)
           throw new IllegalArgumentException("No CredentialsProcessor registered for type " + type.toString());
       return p;
}

No entanto, nas classes de implementação do CredencialsProcessor, preciso de recursos injetados, como um PersistenceContext, então eu fiz o CredentialsProcessor interface a @Local interface, e cada um dos implices marcados com @Stateless. Agora eu posso procurá -los no JNDI e usar os recursos injetados.

Mas agora tenho uma desconexão porque não estou mais usando a fábrica. Meu primeiro pensamento foi mudar o getProcessor(CredentialsType) Método para fazer uma pesquisa JNDI e retornar a instância do SLSB necessária, mas preciso configurar e passar o nome JNDI qualificado adequado. Antes de seguir esse caminho, eu queria fazer mais pesquisas sobre práticas aceitas.

Como esse padrão de design é tratado em ejb3 / java ee?-

Answer 1

Quando você começa a brincar com fábricas e o código Java Pojo "real", você basicamente precisa confiar no JNDI.

A injeção de dependência funciona apenas nos componentes gerenciados de um servidor EJB, e isso é basicamente servlets e EJBs.

Quando você está falando do código Java genérico que deseja se referir à EJBS, eles precisam procurar os recursos via Jndi.

A melhor coisa a fazer, nesse caso, é simplesmente escrever uma classe de pesquisa de wrapper cheia de funções estáticas para fazer suas pesquisas JNDI, em vez de ligar para o JNDI diretamente em cada implementação. E depois use isso em suas implementações.

Essa é apenas uma regra geral genérica.

Agora, para o seu caso específico, considere isso.

Você tem:

static {
    PROCESSORS.put(CredentialsType.CSV, new CSVCredentialsProcessor());
}

Isso não é diferente de:

static {
    PROCESSORS.put(CredentialsType.CSV, "java:comp/env/ejb/CSVCredentialProcessorSessionBean");
}

Então, no seu código getProcessor ():

Context c = new InitialContext();
return (CredentialsProcessor) c.lookup(PROCESSORS.get(type));

Veja, basicamente, o código é idêntico e sua interface de fábrica é a mesma para os clientes.

Você precisa "codificar" a chave de pesquisa JNDI, mas está "codificando" os nomes de classe agora, então, como isso é diferente?

Existem algumas possíveis preocupações de portabilidade entre os contêineres, pois todos parecem gostar de usar diferentes identificadores JNDI para nomes de feijão. A maior parte disso pode ser ajustada na implantação, mas, se não, você pode puxar essas teclas para um arquivo de configuração ou o que for.

Em Java EE 6, existem nomes portáteis garantidos. Se você não está portando contêineres hoje, não se preocupe com isso.

Então, basicamente, não é realmente uma desconexão.

Answer 2

Com o EJB3, você geralmente não precisa fazer pesquisas JNDI. EJB3 suporta Injeção de dependência de EJBS e vários outros tipos de recursos. Se o seu atributo de feijão for anotado com @EJB, a dependência será automaticamente injetada pelo contêiner.

Não ter que fazer uma pesquisa JNDI significa que você pode testar seu EJB como um POJO para fins de teste de unidade. Você pode apenas injetar manualmente implementações simuladas de dependências e testá -las sem precisar implantá -las em um contêiner.