Re: [cdi-dev] CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers

Hi Arjan, Just few notes here: * A lot of users think that it's irrelevant what BeanManager instance they're working on. The truth is the spec does not define this, i.e. whether there are multiple BeanManager instances in application or single one. On the other hand, some BeanManager methods assume a specific context. See for example BeanManager.getBeans(Type, Annotation...): "Return the set of beans which have the given required type and qualifiers and are available for injection _in the module or library containing the class into which the BeanManager was injected or the Java EE component from whose JNDI environment namespace the BeanManager was obtained_, according to the rules of typesafe resolution." I believe this implies that a concrete BeanManager reference should never be used outside the "module" it was injected in. Otherwise, methods like getBeans() will not work correctly. * CDI.current().getBeanManager() is IMHO underspecified. Javadoc mentions "the current context" but it's not clear what does it mean. * In Weld, there is a BeanManager per bean archive, but as said above it's just an implementation detail. * WRT you use case - it's even more complicated, because you're referencing a JSF implicit dependency, which is not a regular application bean archive, nor a Java EE module, nor does it contain beans.xml (only extensions). org.jboss.as.weld.WeldProvider returns the BeanManager for the "synthetic" bean archive created for the JSF "module" as you're probably calling CDI.current() from a class located in the JSF lib. JNDI lookup returns the BeanManager for the EAR (I have no idea how JNDI works here). * Last but not least - EARs are problematic and always will be (see for example all the @ApplicationScoped and visibility discussions). Martin Dne 28.4.2016 v 14:15 arjan tijms napsal(a): -- Martin Kouba Software Engineer Red Hat, Czech Republic