java ee - tutorial - ¿Cuándo se destruye un frijol CDI delimitado @Dependent, si obtienes ese frijol a través de Provider.get()?

ejb cdi tutorial

Question

Me @Dependent entender el ciclo de vida efectivo de un @Dependent ámbito @Dependent tanto en CDI 1.0 como en CDI 1.1. Mis experimentos hasta ahora me han llevado a las siguientes conclusiones:

• Un @Dependent ámbito @Dependent no tiene proxy.
• No se @PreDestroy método @PreDestroy cuando se destruye un bean @Dependent .
• Provider.get() siempre crea una nueva instancia de un bean @Dependent .
• Con JBoss 6 / CDI 1.0, un bean @Dependent creado por el @ApplicationScoped Provider<> @ApplicationScoped ''s bean Provider<> se "filtró" porque todavía "pertenece" al Provider .
• No he visto evidencia (todavía) de beans @Dependent filtrado por Provider similares al utilizar WELD 2.1.2.Final/CDI 1.1. (Aunque esto podría deberse a que estos beans @Dependent particulares se crean mediante métodos @Produces ...!)

Veo que CDI 1.1 ha agregado un método destroy() a Instance<> , presumiblemente para solucionar la fuga de memoria en CDI 1.0. ¿Pero qué pasa con el Provider<> ? ¿Todavía se filtra en CDI 1.1? (Y si lo hace, ¿cómo se supone que debes usar Provider.get() ?)

Básicamente, tengo varios @ApplicationScoped beans / @Singleton que yo @Inject Provider campos, y estoy tratando de usar Provider.get() como fábricas para @Dependent y @RequestScoped "helper" beans. Definitivamente no quiero que estos granos "pertenezcan" a sus campos de Provider , ya que necesito que los granos sean recogidos después:

public void updateStuff() {
Helper helper = helperProvider.get();
// use helper...
}

Para mi aplicación CDI 1.0, estaba pensando en arreglar la fuga de memoria "falsificando" mis Provider con un código como este:

provider = new Provider<MyBean>() {
@Override
public MyBean get() {
return getReferenceFor(MyBean.class);
}
};
private <T> T getReferenceFor(Class<T> type) {
Bean<?> bean = beanManager.resolve(beanManager.getBeans(type));
CreationalContext<?> context = beanManager.createCreationalContext(bean);
try {
return (T) beanManager.getReference(bean, bean.getBeanClass(), context);
} finally {
// Destroy this context - which I don''t want to exist anyway.
// I only need a strong reference to a fully @Inject-ed bean!
context.release();
}
}

MyBean es un frijol con ámbito @Dependent sin el método @PreDestroy que solo debe ser recolectado cuando haya terminado. Sin embargo, no puedo encontrar mucha información sobre los Provider , por lo que no puedo decir si estoy armando algún tipo de bomba de tiempo al hacer esto.

Algunos de mis @Dependent alcance @Dependent (que aún @Dependent través de Provider.get() , btw) se crean mediante métodos @Produces . ¿Todavía están en peligro de ser filtrados?

¿Alguien puede aconsejarme por favor?
Gracias,
Chris

Answer 1

De los documentos de Weld en el ciclo de vida de beans @Dependent:

Una instancia de un bean dependiente nunca se comparte entre diferentes clientes o diferentes puntos de inyección. Es estrictamente un objeto dependiente de algún otro objeto. Se crea una instancia cuando se crea el objeto al que pertenece y se destruye cuando se destruye el objeto al que pertenece.

Entonces la inyección del objeto @Dependent no introducirá una fuga en sí misma, simplemente no hay nada que arreglar. Crear un contexto efímero solo para "estar en el lado seguro" es totalmente innecesario porque los beans dependientes no están ligados a un contexto. En lo que se refiere a CDI después de ser inyectados, son objetos Java ordinarios (de gran alcance).
Si necesita lógica de instanciación, póngalo en un método de productor y listo.

Answer 2

No he probado su construcción, pero a mí personalmente, cada vez que necesito buscar un bean programáticamente, prefiero CDI.current().select().get() . Usando esta construcción, puedo confirmar que obtendrás un nuevo bean @Dependent para cada búsqueda. No está vinculado al proveedor (el contenedor CDI en este caso).

Mira esto y esto . Lo que tenemos aquí es una configuración de prueba Arquillian que implementa un Servlet en un servidor "real" ( o "remoto" usando terminología arquiliana ) y emite una solicitud HTTP GET para averiguar qué beans se producen en el interior.

El resultado es que GlassFish 4.1 y WildFly 8.2.0 proporcionarán al código del cliente un nuevo bean @Dependent en cada búsqueda y, si he entendido bien su pregunta, eso es exactamente lo que quiere. ¡Espero eso ayude!