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.
Both approaches yield similar result however, there are two major differences differences.
CDI.current() is something you can do when 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.