* 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.
* Last but not least - EARs are problematic and always will be (see for example all the @ApplicationScoped and visibility discussions).
Dne 28.4.2016 v 14:15 arjan tijms napsal(a):
I noticed a difference between using CDI.current()
and initialContext.lookup("java:comp/BeanManager") when called from
within a container jar (e.g. Mojarra) in a modular application server
With CDI.current() the bean manager I get when called from within
"Weld BeanManager for com.sun.jsf-impl:main.additionalClasses [bean
With initialContext.lookup("java:comp/BeanManager") it's:
Weld BeanManager for example_app.ear/example_app.war/WEB-INF/classes
Where "example_app" is an EAR application that I used for testing.
I wonder, is this difference intended and did I overlook something, or
is it an unfortunate consequence of something? An additional problem is
that not all (modular) application servers act the same here. E.g. in
GlassFish/Payara I get the application bean manager in both cases.
cdi-dev mailing list
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
Red Hat, Czech Republic