CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers

arjan tijms
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
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: CDI.current() vs initialContext.lookup("java:comp/BeanManager") in modular application servers

Martin Kouba
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):

> 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
> [hidden email]
> 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
_______________________________________________
cdi-dev mailing list
[hidden email]
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.
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
[hidden email]
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


_______________________________________________
cdi-dev mailing list
[hidden email]
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.