patrón de la fábrica avaStatic con EJB3 / JBoss

Question

Soy bastante nuevo en EJB y servidores de aplicaciones completo soplado como JBoss, después de haber escrito y trabajado con aplicaciones Java independientes propósito especial para la mayor parte de mi carrera, con un uso limitado de Java EE. Me pregunto cuál es la mejor manera de adaptar un patrón de diseño se utiliza comúnmente para EJB3 y JBoss: el patrón de la fábrica estática. De hecho este es el elemento # 1 en el libro Effective Java de Joshua Bloch (2ª edición)

Actualmente estoy trabajando con la siguiente 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;
}

Sin embargo, en las clases de implementación de CredentialsProcessor, que requieren recursos inyecta como un PersistenceContext, por lo que he hecho la interfaz de CredentialsProcessor una interfaz @Local, y cada uno de los impl de marcado con @Stateless. Ahora puedo mirar hacia arriba en JNDI y el uso de los recursos inyectados.

Pero ahora tengo una desconexión porque no estoy usando la fábrica más. Mi primer pensamiento fue para cambiar el método getProcessor(CredentialsType) hacer una búsqueda JNDI y devolver la instancia SLSB que se requiere, pero luego me necesita para configurar y pasar el nombre JNDI cualificado adecuado. Antes de ir por ese camino, lo que quería hacer más investigación sobre las prácticas aceptadas.

¿Cómo se trata este patrón de diseño en EJB3 / Java EE -?

Answer 1

Al empezar a jugar con las fábricas y el código "real" de Java POJO, que básicamente necesita confiar en JNDI.

La inyección de dependencias sólo funciona en los componentes administrados de un servidor EJB, y eso es básicamente Servlets y EJB.

Cuando se habla de código java genérico que se quiere hacer referencia a los EJB, que necesitan para buscar los recursos propios a través de JNDI.

Lo mejor que puede hacer, en ese caso, es simplemente escribir una clase de búsqueda envoltorio lleno de funciones estáticas que hacer sus búsquedas JNDI, en lugar de llamar directamente JNDI en cada aplicación. Y luego utilizar eso en sus implementaciones.

Eso es sólo una regla general genérico.

Ahora, para su caso específico, considere esto.

Usted tiene:

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

Esto no es diferente de:

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

A continuación, en el código getProcessor ():

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

Ver, básicamente, el código es idéntico, y la interfaz de fábrica es el mismo para los clientes.

Tienes que la clave de búsqueda JNDI "codificar", pero que está "codificación duro" los nombres de las clases ahora de todos modos, así que ¿cómo es esto diferente?

Hay algunas preocupaciones potenciales portabilidad a través de contenedores, en el que todo el mundo parece que le gusta utilizar diferentes identificadores JNDI para los nombres de frijol. La mayoría de los que pueden ser ajustados en el despliegue, pero si no, entonces se puede tirar estas teclas en un archivo de configuración, o lo que sea.

En Java EE 6, no están garantizados nombres portátiles. Si usted no está portar contenedores hoy, entonces no se preocupe por esto en absoluto.

Así que, básicamente, no es realmente una falta de conexión en absoluto.

Answer 2

Con EJB3, por lo general, no es necesario hacer búsquedas JNDI. soportes EJB3 dependencia inyección de EJB y varios otros tipos de recursos. Si el atributo de frijol se anota con @EJB, la dependencia automáticamente se inyectará por el contenedor.

No tener que hacer una consulta de medios JNDI puede probar sus EJB POJO como una unidad para propósitos de prueba. Usted puede simplemente inyectar manualmente implementaciones simuladas de las dependencias y prueba de ellos sin tener que desplegar en un recipiente.