[cdi-dev] CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers
arjan.tijms at gmail.com
Fri Apr 29 05:39:38 EDT 2016
On Fri, Apr 29, 2016 at 9:30 AM, Martin Kouba <mkouba at redhat.com> wrote:
> * 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
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 "synthetic"
> 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 for
> 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
>> cdi-dev at lists.jboss.org
>> 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.
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev