2010-07-26 24 views
7

Tengo una aplicación JavaEE6, que consta de elementos web y EJB y que se implementa como WAR-only (utilizando EJB3.1). La construcción se basa en Maven. Acabo de leer sobre una nueva posibilidad de ordenar la inicialización del módulo en Java EE 6 here que también necesito para mi aplicación. Además, me gustaría tener una opción para definir algunas propiedades de EJB en XML.Aplicación EJB 3.1 implementada como WAR-only: ¿qué pasa con ejb-jar.xml?

Como el ejemplo se implementa como un proyecto EAR, el orden se define en la aplicación.xml. Pero en un proyecto implementado por WAR, no hay application.xml. Ahora me pregunto dónde puedo definir tales informaciones. ¿O es posible utilizar una aplicación.xml de alguna manera en una aplicación implementada por WAR?

EDIT:

Vaya no he leído el módulo de pedidos por ejemplo-derecha, en un primer momento pensé que era sobre el orden en que los EJB en mi aplicación se cargan. Por supuesto, tengo solo un módulo en mi aplicación WAR, por lo que ordenar no tiene sentido.

Ok, pero como estoy en ello, queda una gran pregunta (también alteró el título de la pregunta para reflejar el cambio): ¿Qué pasa con el ejb-jar.xml? ¿Puedo de alguna manera definir cosas sobre mis EJB en XML (ya que es útil para algunas configuraciones, para evitar la recompilación)?

+0

Notó su edición, buena pregunta por cierto. He actualizado mi respuesta. –

Respuesta

9

En resumen, no es posible con una implementación basada en WAR.

La función de inicialización del módulo de Java EE 6 está destinada a inicializar diferentes módulos de una aplicación en un orden específico. En el momento en que tiene una aplicación EJB basada en WAR, ya no tiene módulos separados para su aplicación EJB y Web. Solo hay un módulo: el módulo de aplicación web en una implementación basada en WAR.

Por lo tanto, si usted tiene que conseguir la misma función que el orden de inicialización del módulo, ofrecido en Java EE 6, que tendrá que realizar una de las siguientes:

  • independiente del EJB en un módulo separado y usa una implementación basada en EAR.
  • Esto es más o menos engañoso, como se hizo en Java EE 5, y usted querrá evitarlo. Es posible que desee codificar en lógica para asegurarse de que se hayan creado los EJB únicos (suponiendo que esto se deba al uso de singletons en su aplicación), antes de que se utilicen en el código.

Ubicación del EJB-jar.xml en un archivo WAR

The EJB 3.1 specification (en el capítulo sobre Embalaje) aborda el tema de la ubicación del archivo ejb-jar.xml cuando se despliega en una GUERRA:

En un archivo .war, el descriptor de despliegue se almacena con el nombre WEB-INF/ejb-jar.xml.

PD: Todavía no he probado este estilo de implementación. YMMV.

+0

¡Gracias por la información! Acabo de alterar mi pregunta, ver mi edición. – ifischer

+3

Como nota al margen, PUEDE empaquetar sus EJB en un EJB-JAR y desplegarlos dentro de un WAR. –

5

Nota al margen sobre los EJB en el procesamiento .wars y ejb-jar.xml. Como ya se mencionó, la ubicación es WEB-INF/ejb-jar.xml, pero también tenga en cuenta que solo se registró la ubicación incluso si hay jarrones ejbs dentro de WEB-INF/lib/- a través de reglas estándar cualquier META-INF/Los archivos ejb-jar.xml se ignoran.

El grupo de expertos estaba bastante dividido en eso, por lo que si tiene una preferencia, no es demasiado tarde para enviar comentarios a la lista de grupos de expertos de EJB 3.1 para su consideración en EJB.next.

Mi voto consistía en permitir que los archivos jar individuales tuvieran archivos META-INF/ejb-jar.xml de la misma manera que estos archivos pueden tener ahora persistence.xmls, beans.xmls, fragmentos web, etc. El problema más importante para mí fue que está en desacuerdo con Embedded EJB Container API que admite un classpath EAR-style que permite varios tarros/módulos que posiblemente contengan un archivo META-INF/ejb-jar.xml. El resultado es que si usa la API integrada para probar una aplicación ejb multibolsas compuesta en un único archivo .war, entonces se enfrenta a la tarea de fusionar cualquier archivo ejb-jar.xml que tenga en un único ejb. -jar.xml para la aplicación web. Una especie de dolor para los usuarios.