On Fri, Apr 29, 2016 at 9:30 AM, Martin Kouba <mkouba(a)redhat.com> wrote:
* WRT you use case - it's even more complicated, because
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
True, so if more specs are going to re-base on top of CDI, it may be
important for the CDI spec to explicitly recognise this case?
JSR 375 (Security JSR) and I think MVC would have the exact same problems.
The general use case is that the framework specs need to obtain beans from
the application, as those beans are the plug-in points so to speak for
those frameworks. These can be (CDI) managed converters, validators,
authentication mechanisms, identity stores and what have you.
For now I guess avoiding CDI.current() and solely depending
on initialContext.lookup("java:comp/BeanManager") is the safest choice then.
org.jboss.as.weld.WeldProvider returns the BeanManager for the
bean archive created for the JSF "module" as you're probably calling
CDI.current() from a class located in the JSF lib.
Indeed, while debugging I noticed getBeanManager() internally fell through
to a special case.
* Last but not least - EARs are problematic and always will be (see
example all the @ApplicationScoped and visibility discussions).
I know :( I noticed that Weld uses a fallback bean manager, which seemingly
is the one for just a completely random module in the EAR. And indeed,
bean names and extensions not being isolated between war modules in the ear
have caused many other problems.
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
> (e.g. JBoss/WildFly).
> With CDI.current() the bean manager I get when called from within
> Mojarra is:
> "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
> [bean count=97]
> 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.
> Kind regards,
> Arjan Tijms
> cdi-dev mailing list
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
). 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