¿Tiene sentido CDI si no hay una capa web y, por lo tanto, no hay una sesión HTTP?

Question

El nuevo JSR 299 "Contextos e inyección de dependencias para Java EE" parece estar basado en el concepto de "Alcance".

Los beans se crean y se asocian a uno de los ámbitos aceptados: aplicación, sesión (asignada a una sesión HTTP), conversación y solicitud.

Tiene sentido utilizar CDI si no hay sesión HTTP (por ejemplo, una aplicación Enterprise que expone la funcionalidad a través de la comunicación remota EJB) ya que los beans gestionados no van a asociarse a ningún contexto (ya que no existen)?

¿Es posible usar CDI en tal escenario? ¿Qué ventajas le aportaría?

Answer 1

Me recuerda a mi propia pregunta que hice hace algún tiempo: How does @SessionScoped work with EJB? Is CDI only for web-tier?

Parece que la idea de 'alcance' sólo es relevante en el caso de la sesión HTTP.
Sin embargo, puedo ver un uso válido del alcance @ApplicationScoped como una forma de implementar un bean singleton de aplicación, a pesar de que la solicitud sea HTTP.

Javadoc dice:

El ámbito de aplicación está activa:

(...)

• durante cualquier invocación de servicios web Java EE,

• durante cualquier invocación de método remoto de cualquier EJB, durante cualquier invocación de método asíncrono de cualquier EJB, durante cualquier llamada a un método EJB tiempo de espera y durante la entrega de mensajes a cualquier mensaje-bean EJB ,

Answer 2

También puede crear sus propios ámbitos. CDI es muy extensible y puede usarse en una variedad de situaciones. También se está utilizando en aplicaciones SE donde no hay ni HttpSession ni HttpRequest.

Answer 3

Aparte de eso, CDI no es solo para la gestión del ciclo de vida, puede usarlo para hacer la inyección de dependencias separando las interfaces de sus implementaciones de una manera muy limpia. También puede realizar algunas técnicas de AOP utilizando interceptores y decoradores, o crear un patrón Observer muy flexible aprovechando los eventos de CDI.