<p dir="ltr">No technical reason AFAIK.<br>
</p>
<div class="gmail_quote">Le 1 mars 2015 15:13, &quot;John D. Ament&quot; &lt;<a href="mailto:john.d.ament@gmail.com">john.d.ament@gmail.com</a>&gt; a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So, I think I&#39;ve gathered enough feedback at this point, and seen some of the API changes.  I&#39;ll hopefully be including some doc changes this week, but one question - do we want to start the SE specific stuff as its own asciidoc file?<div><br></div><div>Changes made:</div><div><br></div><div>- Changed return value to CDI&lt;Object&gt; to provide better capability out of the box.</div><div>- Added AutoCloseable to CDIContainer, provided default implementation of calling shutdown.</div><div>- Added synchronization support to the method body that retrieves the singleton instance (BTW, I&#39;m not sure if this is even useful TBH as each impl, including the RI, needs to provide this class in its own format).</div><div>- Made the params map typed to &lt;String,Object&gt;</div><div><br></div><div>@Romain Your case isn&#39;t really supportable yet, until we have static injection support.  You&#39;d still have to have a managed version of Runner to work against.</div><div><br></div><div>John<br><br><div class="gmail_quote">On Sat, Feb 28, 2015 at 4:11 PM Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Yes but not the way to get an instance. Even Unmanaged does it.</p>
<p dir="ltr">What can be awesome is to have static inject for it:</p>
<p dir="ltr">public class Runner {</p>
<p dir="ltr">@Inject<br>
private static MyMain main;</p>
<p dir="ltr">public static void main(String[] arg) {<br>
    try (CDIContainer c = CDIContainer.newContainer()) {<br>
        main.doWork();<br>
    }<br>
}</p>
<p dir="ltr">}</p>
<p dir="ltr">And not a single additional line :).<br>
</p>
<div class="gmail_quote">Le 28 févr. 2015 19:05, &quot;John D. Ament&quot; &lt;<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>&gt; a écrit :</div><div class="gmail_quote"><br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Maybe I&#39;m misreading, but I don&#39;t see us adding another API to do the same thing here - we&#39;re introducing new functionality.<div><br></div><div>CDIContainer/Loader on startup/shutdown of the application</div><div><br></div><div>CDI for runtime usage within the application to interact with the container.</div><div><br></div><div>John<br><br><div class="gmail_quote">On Fri, Feb 27, 2015 at 3:40 AM Romain Manni-Bucau &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sure I fully agree excepted I think introducing yet another API to do<br>
the same thing is not good so super tempting to skip it and wait for<br>
feedbacks rather than introducing it eagerly.<br>
<br>
<br>
Romain Manni-Bucau<br>
@rmannibucau<br>
<a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
<a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.<u></u>com</a><br>
<a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
<br>
<br>
2015-02-27 8:05 GMT+01:00 Jozef Hartinger &lt;<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>&gt;:<br>
&gt; My point is that from the application perspective, the user obtains one<br>
&gt; container handle for eventual shutdown (CDIContainer) and then looks up a<br>
&gt; different container handle (CDI) that they can use for real work (lookup /<br>
&gt; event dispatch / etc.) It would be cleaner if the container gave away a<br>
&gt; single handle that can do all of that.<br>
&gt;<br>
&gt;<br>
&gt; On 02/26/2015 05:42 PM, Romain Manni-Bucau wrote:<br>
&gt;<br>
&gt; Not sure I get how a CDI instance can help.<br>
&gt;<br>
&gt; But container.getBeanManager() sounds nice is not a shortcut for<br>
&gt; CDI.current().getBm() otherwise it looks like duplication to me.<br>
&gt;<br>
&gt; Can we make container not contextual - dont think so? If so it makes sense<br>
&gt; otherwise I fear it doesnt add much.<br>
&gt;<br>
&gt; Le 26 févr. 2015 16:19, &quot;Jozef Hartinger&quot; &lt;<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>&gt; a écrit :<br>
&gt;&gt;<br>
&gt;&gt; I like the initialize + close() combination and the try-with-resources<br>
&gt;&gt; usage.<br>
&gt;&gt; What looks weird to me is that at line one you obtain a container handle:<br>
&gt;&gt;<br>
&gt;&gt; try (CDIContainer container = CDIContainer.newCDIContai...<br>
&gt;&gt; CDI.current().getBeanManager() ...<br>
&gt;&gt;<br>
&gt;&gt; and then at line two you call a static method to perform a container<br>
&gt;&gt; lookup :-/<br>
&gt;&gt;<br>
&gt;&gt; An API that allows you to use the container handle you already got is way<br>
&gt;&gt; better IMO, e.g.:<br>
&gt;&gt;<br>
&gt;&gt; try (CDIContainer container = CDIContainer.newCDIContai...<br>
&gt;&gt; container.getBeanManager()<br>
&gt;&gt;<br>
&gt;&gt; If CDIContainer.newCDIContainer() returns an CDI instance or its subclass,<br>
&gt;&gt; we get this easily.<br>
&gt;&gt;<br>
&gt;&gt; On 02/26/2015 08:58 AM, Romain Manni-Bucau wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi guys<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; why note keeping it simple?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; try (CDIContainer container = CDIContainer.newCDIContainer(/<u></u>* optional<br>
&gt;&gt;&gt; map to configure vendor features */)) {<br>
&gt;&gt;&gt;       CDI.current().getBeanManager()<u></u>....<br>
&gt;&gt;&gt; }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Not sure the point having initialize() + having shutdown = close<br>
&gt;&gt;&gt; really makes the API more fluent and modern IMO.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Also to be fully SE I guess provider() method would be needed even if<br>
&gt;&gt;&gt; optional (SPI usage by default):<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; try (CDIContainer container =<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; CDIContainer.provider(&quot;org.<u></u>jboss.weld.<u></u>WeldCdiContainerProvider&quot;).<u></u>newCDIContainer())<br>
&gt;&gt;&gt; {<br>
&gt;&gt;&gt;       CDI.current().getBeanManager()<u></u>....<br>
&gt;&gt;&gt; }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Finally I think having a kind of getInstance shortcut could be a plus for<br>
&gt;&gt;&gt; SE:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; try (CDIContainer container = CDIContainer.newCDIContainer()<u></u>) {<br>
&gt;&gt;&gt;       container.newInstance(<u></u>MyAppRunner.class /* optional qualifiers */<br>
&gt;&gt;&gt; ).run(args);<br>
&gt;&gt;&gt; }<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Using container to get an instance would create the instance and bind<br>
&gt;&gt;&gt; it to the container lifecycle (mainly for predestroy) avoiding this<br>
&gt;&gt;&gt; boilerplate code in all main which will surely only be used to launch<br>
&gt;&gt;&gt; a soft.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; wdyt?<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Romain Manni-Bucau<br>
&gt;&gt;&gt; @rmannibucau<br>
&gt;&gt;&gt; <a href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
&gt;&gt;&gt; <a href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.<u></u>com</a><br>
&gt;&gt;&gt; <a href="https://github.com/rmannibucau" target="_blank">https://github.com/rmannibucau</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2015-02-26 8:32 GMT+01:00 Jozef Hartinger &lt;<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>&gt;:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Comments inline<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On 02/25/2015 05:53 PM, John D. Ament wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Sorry Jozef, your email fell into the pits of google inbox&#39;s &quot;smart<br>
&gt;&gt;&gt;&gt; sorting&quot;<br>
&gt;&gt;&gt;&gt; features.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Thu, Feb 12, 2015 at 3:18 AM Jozef Hartinger &lt;<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>&gt;<br>
&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Hi John, comments inline:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On 02/11/2015 06:02 PM, John D. Ament wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Jozef,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Most of what you see there is taken from the original doc, since<br>
&gt;&gt;&gt;&gt;&gt; everyone<br>
&gt;&gt;&gt;&gt;&gt; seemed to be in agreement.  I think the map is just a safeguard in case<br>
&gt;&gt;&gt;&gt;&gt; of<br>
&gt;&gt;&gt;&gt;&gt; additional boot options available in some implementations (e.g. I think<br>
&gt;&gt;&gt;&gt;&gt; OWB/OpenEJB have some options.. currently OpenEJB supports an embedded<br>
&gt;&gt;&gt;&gt;&gt; CDI<br>
&gt;&gt;&gt;&gt;&gt; boot mode).<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; No, I am fine with the map. What I am questioning is the type of the<br>
&gt;&gt;&gt;&gt;&gt; map.<br>
&gt;&gt;&gt;&gt;&gt; Usually, data structures with a similar purpose use Strings as their<br>
&gt;&gt;&gt;&gt;&gt; keys.<br>
&gt;&gt;&gt;&gt;&gt; This applies to ServletContext attributes, InvocationContext data,<br>
&gt;&gt;&gt;&gt;&gt; Servlet<br>
&gt;&gt;&gt;&gt;&gt; request/session attributes and others. I am therefore wondering whether<br>
&gt;&gt;&gt;&gt;&gt; there is a usecase for the proposed unbound key signature or not.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I think that&#39;s more of a placeholder, I was assuming it would be<br>
&gt;&gt;&gt;&gt; Map&lt;String,Object&gt; once we clarify everything.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; We spoke a few times about BeanManager vs CDI.  BeanManager was<br>
&gt;&gt;&gt;&gt;&gt; preferable<br>
&gt;&gt;&gt;&gt;&gt; since there&#39;s no easy way to get the the instance, CDI is easier to get<br>
&gt;&gt;&gt;&gt;&gt; and<br>
&gt;&gt;&gt;&gt;&gt; more aligned with how you would get it.  Usually people expect the<br>
&gt;&gt;&gt;&gt;&gt; BeanManager to be injected or available via JNDI, neither would be the<br>
&gt;&gt;&gt;&gt;&gt; case<br>
&gt;&gt;&gt;&gt;&gt; here.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; If CDI 2.0 targets Java SE then this container initialization API will<br>
&gt;&gt;&gt;&gt;&gt; become something that ordinary application developers use to start/stop<br>
&gt;&gt;&gt;&gt;&gt; CDI<br>
&gt;&gt;&gt;&gt;&gt; in their applications. It therefore cannot be considered an SPI but<br>
&gt;&gt;&gt;&gt;&gt; instead<br>
&gt;&gt;&gt;&gt;&gt; should be something easy to use. On the other hand, BeanManager is<br>
&gt;&gt;&gt;&gt;&gt; definitely an SPI. It is used in extension, frameworks and generally<br>
&gt;&gt;&gt;&gt;&gt; for<br>
&gt;&gt;&gt;&gt;&gt; integration. Not much by applications directly. Therefore, I don&#39;t see<br>
&gt;&gt;&gt;&gt;&gt; how<br>
&gt;&gt;&gt;&gt;&gt; the container bootstrap API and BeanManager fit together. IMO the<br>
&gt;&gt;&gt;&gt;&gt; bootstrap<br>
&gt;&gt;&gt;&gt;&gt; API should expose something that makes common tasks (obtaining a<br>
&gt;&gt;&gt;&gt;&gt; contextual<br>
&gt;&gt;&gt;&gt;&gt; reference and firing and event) easy, which the CDI class does.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Plus do not forget that BeanManager can be obtained easily using<br>
&gt;&gt;&gt;&gt;&gt; CDI.getBeanManager().<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;m not disagreeing.  There&#39;s a few things I&#39;d consider:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - Is this mostly for new apps or existing?  If existing, it&#39;s probably<br>
&gt;&gt;&gt;&gt; using<br>
&gt;&gt;&gt;&gt; some internal API, if new it can use whatever API we give.<br>
&gt;&gt;&gt;&gt; - I don&#39;t want to return void, we should give some kind of reference<br>
&gt;&gt;&gt;&gt; into<br>
&gt;&gt;&gt;&gt; the container when we&#39;re done booting.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Agreed, we should not be returning void.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - CDI is a one step retrievable reference, where as BeanManager is a two<br>
&gt;&gt;&gt;&gt; step reference.  With that said, BeanManager makes more sense to return<br>
&gt;&gt;&gt;&gt; here.  Another thought could be we invent some new class that has both,<br>
&gt;&gt;&gt;&gt; but<br>
&gt;&gt;&gt;&gt; that&#39;s really redundant.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Why do you think BeanManager makes more sense here? Especially given the<br>
&gt;&gt;&gt;&gt; assumption that application code is going to call this init/shutdown<br>
&gt;&gt;&gt;&gt; API, I<br>
&gt;&gt;&gt;&gt; don&#39;t see BeanManager as making more sense.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Yes, this is the container start API.  Sounds like you have some good<br>
&gt;&gt;&gt;&gt;&gt; ideas for things like XML configuration or programmatic configuration,<br>
&gt;&gt;&gt;&gt;&gt; both<br>
&gt;&gt;&gt;&gt;&gt; of which are being tracked under separate tickets.  One idea might be<br>
&gt;&gt;&gt;&gt;&gt; for an<br>
&gt;&gt;&gt;&gt;&gt; optional param in the map to control packages to scan/ignore, in that<br>
&gt;&gt;&gt;&gt;&gt; map.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I am wondering whether this configuration should be something optional<br>
&gt;&gt;&gt;&gt;&gt; built on top of the bootstrap API or whether we should consider making<br>
&gt;&gt;&gt;&gt;&gt; it<br>
&gt;&gt;&gt;&gt;&gt; mandatory. Either way, we cannot add the bootstrap API to the spec<br>
&gt;&gt;&gt;&gt;&gt; without<br>
&gt;&gt;&gt;&gt;&gt; explicitly defining how it behaves. My implicit assumption of the<br>
&gt;&gt;&gt;&gt;&gt; proposal<br>
&gt;&gt;&gt;&gt;&gt; is that the container is supposed to scan the entire classpath for<br>
&gt;&gt;&gt;&gt;&gt; explicit<br>
&gt;&gt;&gt;&gt;&gt; or implicit bean archives (including e.g. rt.jar), discover beans, fire<br>
&gt;&gt;&gt;&gt;&gt; extensions, etc. This worries me as this default behavior is far from<br>
&gt;&gt;&gt;&gt;&gt; being<br>
&gt;&gt;&gt;&gt;&gt; lightweight, which CDI for Java SE initially aimed to be.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Yes, the spec must be updated to reflect the behavior of SE mode.  I<br>
&gt;&gt;&gt;&gt; plan to<br>
&gt;&gt;&gt;&gt; get that completely into the google doc before opening any spec changes<br>
&gt;&gt;&gt;&gt; in a<br>
&gt;&gt;&gt;&gt; PR.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; We didn&#39;t want to over load the CDI interface.  It already does a lot.<br>
&gt;&gt;&gt;&gt;&gt; This is really SPI code, CDI even though it&#39;s in the spi package is<br>
&gt;&gt;&gt;&gt;&gt; used in<br>
&gt;&gt;&gt;&gt;&gt; a lot of application code.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I would personally prefer to have it all in one place. Having<br>
&gt;&gt;&gt;&gt;&gt; CDIContainer, CDIContainerLoader, CDI and CDIProvider makes it more<br>
&gt;&gt;&gt;&gt;&gt; difficult to know when to use what.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The problem is that most CDI (the interface) operations are against a<br>
&gt;&gt;&gt;&gt; running container.  I think we spoke about leveraging CDIProvider at one<br>
&gt;&gt;&gt;&gt; point (in fact, I mistakenly called CDIContainer CDIProvider not even<br>
&gt;&gt;&gt;&gt; realizing it was there).  I doubt that most app developers use it<br>
&gt;&gt;&gt;&gt; currently,<br>
&gt;&gt;&gt;&gt; there&#39;s not even a way to get a reference to it that I&#39;m aware of.  It&#39;s<br>
&gt;&gt;&gt;&gt; used by the implementor only.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I don&#39;t think there&#39;s a conflict. CDI class would still only provide<br>
&gt;&gt;&gt;&gt; methods<br>
&gt;&gt;&gt;&gt; to be run against a running container. The difference is that there<br>
&gt;&gt;&gt;&gt; would be<br>
&gt;&gt;&gt;&gt; additional static methods to get this running container (CDI class) to<br>
&gt;&gt;&gt;&gt; you<br>
&gt;&gt;&gt;&gt; by starting the container.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Either way, I agree that reusing CDIProvider is a must. There is no<br>
&gt;&gt;&gt;&gt; reason<br>
&gt;&gt;&gt;&gt; to define a new class for the same purpose.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I expect that my changes in the CDI spec around this will state, along<br>
&gt;&gt;&gt;&gt; the<br>
&gt;&gt;&gt;&gt; lines of:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; To retrieve a CDIContainer to launch, do this:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; CDIContainer container = CDIContainerLocator.<u></u>getCDIContainer();<br>
&gt;&gt;&gt;&gt; container.initialize();<br>
&gt;&gt;&gt;&gt; ... do work<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Once you want to shutdown the container, do this:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; container.shutdown();<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; (we may want to consider implementing AutoCloseable, an oversight on my<br>
&gt;&gt;&gt;&gt; part)<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; and then later on<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - What happens if I call CDIContainerLocator in an app server<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - It throws an IllegalStateException.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; - The container provides no beans of type CDIContainer, it is managed<br>
&gt;&gt;&gt;&gt; outside of the CDI container.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; John<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Wed Feb 11 2015 at 4:21:50 AM Jozef Hartinger &lt;<a href="mailto:jharting@redhat.com" target="_blank">jharting@redhat.com</a>&gt;<br>
&gt;&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Hi John, some thoughts:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; - instead of using BeanManager it makes more sense to me to return a<br>
&gt;&gt;&gt;&gt;&gt;&gt; CDI<br>
&gt;&gt;&gt;&gt;&gt;&gt; instance, which is a more user-friendly API (and it also exposes<br>
&gt;&gt;&gt;&gt;&gt;&gt; access to<br>
&gt;&gt;&gt;&gt;&gt;&gt; BeanManager)<br>
&gt;&gt;&gt;&gt;&gt;&gt; - is there a usecase for arbitrary keys of the &quot;params&quot; map or is<br>
&gt;&gt;&gt;&gt;&gt;&gt; Map&lt;String, ?&gt; sufficient?<br>
&gt;&gt;&gt;&gt;&gt;&gt; - if we could move the shutdown() method from CDIContainer to the<br>
&gt;&gt;&gt;&gt;&gt;&gt; actual<br>
&gt;&gt;&gt;&gt;&gt;&gt; container handle that we obtain from initialize(), that would look<br>
&gt;&gt;&gt;&gt;&gt;&gt; more<br>
&gt;&gt;&gt;&gt;&gt;&gt; object-oriented<br>
&gt;&gt;&gt;&gt;&gt;&gt; - what exactly is initialize() supposed to do? Is it supposed to start<br>
&gt;&gt;&gt;&gt;&gt;&gt; scanning the entire classpath for CDI beans? That could be a problem<br>
&gt;&gt;&gt;&gt;&gt;&gt; especially with spring-boot-like fat jars. I think we need an API to<br>
&gt;&gt;&gt;&gt;&gt;&gt; tell<br>
&gt;&gt;&gt;&gt;&gt;&gt; the container which classes / packages to consider. Something like<br>
&gt;&gt;&gt;&gt;&gt;&gt; Guice&#39;s<br>
&gt;&gt;&gt;&gt;&gt;&gt; binding API perhaps?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; - the proposal makes me wonder whether retrofitting this functionality<br>
&gt;&gt;&gt;&gt;&gt;&gt; to<br>
&gt;&gt;&gt;&gt;&gt;&gt; the CDI class wouldn&#39;t be a better option. It could look like:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; CDI container = CDI.initialize();<br>
&gt;&gt;&gt;&gt;&gt;&gt; container.select(Foo.class).<u></u>get();<br>
&gt;&gt;&gt;&gt;&gt;&gt; container.shutdown();<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; compare it to:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; CDIContainer container = CDIContainerLoader. getCDIContainer();<br>
&gt;&gt;&gt;&gt;&gt;&gt; BeanManager manager = container.initialize();<br>
&gt;&gt;&gt;&gt;&gt;&gt; manager.getBeans(...);<br>
&gt;&gt;&gt;&gt;&gt;&gt; container.shutdown(manager);<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; On 02/10/2015 06:58 PM, John D. Ament wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; All,<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I have the updated API here, and wanted to solicit any final feedback<br>
&gt;&gt;&gt;&gt;&gt;&gt; before updating the google doc and spec pages.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://github.com/johnament/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c" target="_blank">https://github.com/johnament/<u></u>cdi/commit/<u></u>2c362161e18dd521f8e83c27151dda<u></u>d467a1c01c</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Let me know your thoughts.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; John<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; ______________________________<u></u>_________________<br>
&gt;&gt;&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider licenses<br>
&gt;&gt;&gt;&gt;&gt;&gt; the<br>
&gt;&gt;&gt;&gt;&gt;&gt; code under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/<u></u>licenses/LICENSE-2.0.html</a>). For all other ideas<br>
&gt;&gt;&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; ______________________________<u></u>_________________<br>
&gt;&gt;&gt;&gt; cdi-dev mailing list<br>
&gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/<u></u>mailman/listinfo/cdi-dev</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Note that for all code provided on this list, the provider licenses the<br>
&gt;&gt;&gt;&gt; code<br>
&gt;&gt;&gt;&gt; under the Apache License, Version 2<br>
&gt;&gt;&gt;&gt; (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" target="_blank">http://www.apache.org/<u></u>licenses/LICENSE-2.0.html</a>). For all other ideas<br>
&gt;&gt;&gt;&gt; provided on this list, the provider waives all patent and other<br>
&gt;&gt;&gt;&gt; intellectual<br>
&gt;&gt;&gt;&gt; property rights inherent in such information.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
</blockquote></div></div></div>
</blockquote></div></blockquote></div></div></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" 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" 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>