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

[arjan tijms]

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
> extensions).


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.

Kind regards,
Arjan Tijms




>
> Martin
>
> Dne 28.4.2016 v 14:15 arjan tijms napsal(a):
>
>> Hi,
>>
>> 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
>> count=44]"
>>
>>
>> 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
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> 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...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160429/ed9e2308/attachment.html