In the context of JEE/CDI, I find myself typically using a CDI static function when I need to retrieve a CDI managed bean statically from a method. For instance:
MyBean myBean = CDI.current().select( MyBean.class ).get()
However, from what I can tell, another equivalent way to accomplish this is using the BeanManager:
BeanManger bm = new InitialContext().lookup( "java:comp/BeanManager" );
Bean<?> bean = bm.resolve(bm.getBeans( MyBean.class ) );
CreationalContext<?> context = bm.createCreationalContext(bean);
MyBean myBean = bm.getReference(bean, cls, context);
So other than being significantly less code to write using the CDI.current()
method, what differences are there in using it? It would seem that reverting to using the BeanManager
is a much more complex (and potentially error prone?) methodology. From a functional perspective, are there any drawbacks in using the CDI.current()
method instead? Does CDI...select()
only work for an @ApplicationScope
bean? Or can I use with other scoped beans (ex: @Dependent
) as well?
I remember reading something about potentially memory leaks using the CDI method, but do not understand how or why this could be the case.
But what is a CDI bean? A CDI bean is a POJO, plain old java object, that has been automatically instantiated by the CDI container, and is injected into all, and any qualifying injection points in the application. The CDI container initiates the bean discovery process during deployment.
CDI is preferred because it allows apps of large (arbitrary?) horizontal and vertical scales to share contexts, dependencies, and therefore data.
CDI (Contexts and Dependency Injection) is a standard dependency injection framework included in Java EE 6 and higher. It allows us to manage the lifecycle of stateful components via domain-specific lifecycle contexts and inject components (services) into client objects in a type-safe way.
Both approaches yield similar result however, there are two major differences differences.
CDI.current()
is something you can you where you cannot simply @Inject BeanManager
.
Instance.get()
doesn't take a CreationalContext
parameter whereas BM.getReference()
does.
Instance
, the CreationalContext
is managed by container - you needn't care about it and especially about releasing the context. If you are using BM.getReference()
you firstly need to obtain that context which usually means creating it and that holds you responsible to also release it once you are done working with it.If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With