<div dir="ltr">Hi,<div><br></div><div>Thanks for the writeup!</div><div><br></div><div>A couple of things spring to mind. One thing is to clarify which version of the bean manager @Inject, CDI.current() and a JNDI lookup should get/use.</div><div><br></div><div>Depending on the outcome of that, maybe it's useful to define several constants and/or JNDI entries to more specifically define which bean manager should be used.</div><div><br></div><div>E.g.</div><div><br></div><div>CDI.current(CONTAINER) // Only sees beans in the container archive</div><div>CDI.current(APPLICATION) // Only sees beans in the application archive</div><div>CDI.current(CONTAINER, APPLICATION) // beans in container and application <br></div><div>etc</div><div><br></div><div>In an EAR there are even some more options, but EARS and CDI are already problematic, so maybe not go there just yet.</div><div><br></div><div>Similar variations may be used for JNDI lookups:</div><div><br></div><div>initialContext.lookup("java:comp/BeanManagers/container")<br></div><div>initialContext.lookup("java:comp/BeanManagers/application")<br></div><div>initialContext.lookup("java:comp/BeanManagers/container_application")<br></div><div><br></div><div>Not sure if this is the best way forward, but just throwing the idea out there.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 19, 2016 at 6:47 PM, Christian Kaltepoth <span dir="ltr"><<a href="mailto:christian@kaltepoth.de" target="_blank">christian@kaltepoth.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hey all,</div><div><br></div><div>I would like to bring up an issue that we ran into while preparing Ozark (the MVC 1.0 RI) to be usable as a container module in Glassfish. We discussed this issue on Slack and discovered that Mojarra (JSF) and Soteria (Security) had similar issues.</div><div><br></div><div>MVC 1.0 defines some extension points that users and 3rd party libraries can implement to provide additional functionality. MVC uses CDI for looking up all implementations of these extension point interfaces. Similar concepts are used in in JSF. Historically JSF uses factories which users can implement and register via faces-config.xml. Now for Java EE 8 it was decided to prefer CDI to obtain such custom extension point implementations (ViewHandler, NavigationHandler, etc). So basically JSF uses a similar mechanism to lookup implementations of certain interfaces like MVC does.</div><div><br></div><div>As of today Ozark is basically a standard bean archive deployed together with the application (in /WEB-INF/lib). Now we want to prepare Ozark to be usable as a Glassfish module which is provided by the container. As CDI doesn't discover bean archives installed as part of the container, we wanted to basically remove beans.xml and provide an portable extension which registers the required annotated types required for Ozark. AFAIK Mojarra and Soteria are also doing it this way. Now as soon as we do this, things are getting weird.</div><div><br></div><div>There are various ways to get a BeanManager to lookup beans provided by the application:</div><div><ul><li>CDI.current().getBeanManager()<br></li><li>@Inject BeanManager</li><li>JNDI lookup</li></ul><div>Now if we try to lookup beans deployed with the application (in /WEB-INF/classes or in a library in /WEB-INF/lib) we don't get consistent results (many thanks to Arjan Tijms for doing all the testing):</div></div><div><ul><li>In Glassfish we don't see application beans if we use the injected BeanManager. Looking up the BeanManager via JNDI or using CDI.current().getBeanManager() works fine.</li><li>In Wildfly CDi.current() doesn't seem to find beans deployed with the application. The injected BeanManager and the one looked up via JNDI works fine.</li></ul></div><div>So it looks like there are quite some inconsistencies between implementations here.</div><div><br></div><div><u>To sum it up:</u> In Java EE 8 more and more specs rely heavily on CDI. And many specs allow the user and 3rd party libraries to implement interfaces to extend functionality. But it looks like looking up such beans deployed with the application from a container archive isn't working in a consistent way.</div><div><br></div><div>I hope my explanation of this complicated topic isn't too bad. I hope that we can start some discussion around this. Some of you already joined the discussion on Slack and the corresponding pull request, but I would prefer to discuss this here. :)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Christian</div><div><br></div><div><br></div>-- <br><div><div>Christian Kaltepoth</div><div>Blog: <a href="http://blog.kaltepoth.de/" target="_blank">http://blog.kaltepoth.de/</a></div><div>Twitter: <a href="http://twitter.com/chkal" target="_blank">http://twitter.com/chkal</a></div><div>GitHub: <a href="https://github.com/chkal" target="_blank">https://github.com/chkal</a></div><div><br></div></div>
</font></span></div>
<br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">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></blockquote></div><br></div>