<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 29, 2016 at 9:30 AM, Martin Kouba <span dir="ltr"><<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">* 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). </blockquote><div><br></div><div>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?</div><div><br></div><div>JSR 375 (Security JSR) and I think MVC would have the exact same problems.</div><div><br></div><div>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.</div><div><br></div><div>For now I guess avoiding CDI.current() and solely depending on initialContext.lookup("java:comp/BeanManager") is the safest choice then.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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. </blockquote><div><br></div><div>Indeed, while debugging I noticed getBeanManager() internally fell through to a special case.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">* Last but not least - EARs are problematic and always will be (see for example all the @ApplicationScoped and visibility discussions).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Martin<br>
<br>
Dne 28.4.2016 v 14:15 arjan tijms napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">
Hi,<br>
<br>
I noticed a difference between using CDI.current()<br>
and initialContext.lookup("java:comp/BeanManager") when called from<br>
within a container jar (e.g. Mojarra) in a modular application server<br>
(e.g. JBoss/WildFly).<br>
<br>
With CDI.current() the bean manager I get when called from within<br>
Mojarra is:<br>
<br>
"Weld BeanManager for com.sun.jsf-impl:main.additionalClasses [bean<br>
count=44]"<br>
<br>
<br>
With initialContext.lookup("java:comp/BeanManager") it's:<br>
<br>
Weld BeanManager for example_app.ear/example_app.war/WEB-INF/classes<br>
[bean count=97]<br>
<br>
Where "example_app" is an EAR application that I used for testing.<br>
<br>
I wonder, is this difference intended and did I overlook something, or<br>
is it an unfortunate consequence of something? An additional problem is<br>
that not all (modular) application servers act the same here. E.g. in<br>
GlassFish/Payara I get the application bean manager in both cases.<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br></div></div>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br><span class=""><font color="#888888">
</font></span></blockquote><span class=""><font color="#888888">
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</font></span></blockquote></div><br></div></div>