<div dir="ltr">Just to clarify a few more things.<div><br></div><div>The use of </div><div><br></div><div>CDIContainer container = CDIContainerLoader.getCDIContainer();</div><div><br></div><div>Was meant to emulate the boot process used in several other specs that have SE equivalents, e.g. JPA and Bean Validation, which use a locator type to give a factory, and that factory giving what you typically work with.</div><div><br></div><div>John<br><br><div class="gmail_quote">On Wed, Mar 4, 2015 at 7:59 AM Jozef Hartinger &lt;<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    UnmanagedInstance is provided to make it easier for libraries to
    perform dependency injection on classes that are for some reason not
    CDI beans. It should not be a substitute for lookup of CDI beans.
    Therefore, I do not see UnmanagedInstance fitting here.</div><div text="#000000" bgcolor="#FFFFFF"><br>
    <br>
    <div>On 03/04/2015 01:47 PM, Romain
      Manni-Bucau wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hmm
        <div><br>
        </div>
        <div>I think one of the main point I try to push is we have a
          bunch of API to do it already, if we need yet another API to
          do the same we have several choices:</div>
        <div>- we love creating APIs</div>
        <div>- all previous APIs are failures and should be deprecated
          or fixed</div>
        <div>- there is a full mismatch with embedded and EE case (but
          we have existing proofs it is not the case)</div>
        <div><br>
        </div>
        <div>I think we should help user to not be lost between all APIs
          and I strongly believe we can&#39;t do anything on container to
          lookup beans (EJBContainer#getContext was a try which is close
          to it but it actually just limited user experience compared to
          existing solutions).</div>
        <div><br>
        </div>
        <div>What&#39;s the issue with UnmanagedInstance?</div>
        <div><br>
        </div>
      </div>
      <div class="gmail_extra"><br clear="all">
        <div>
          <div>
            <div dir="ltr">
              <div>
                <div dir="ltr">
                  <div>
                    <div dir="ltr">
                      <div>
                        <div dir="ltr">
                          <div><br>
                            <span style="font-size:small">Romain
                              Manni-Bucau</span><br>
                            <a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> |  <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
        <br>
        <div class="gmail_quote">2015-03-04 13:43 GMT+01:00 Jozef
          Hartinger <span dir="ltr">&lt;<a href="mailto:jharting@redhat.com" target="_blank" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">jharting@redhat.com</a>&gt;</span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div text="#000000" bgcolor="#FFFFFF"> The only argument I
              found supporting a strict separation of those two APIs is
              that it makes it easier to control when a user should or
              should not use boot (i.e. it should not be used in EE for
              example).<br>
              <br>
              That&#39;s a good argument. It&#39;s not however necessarily only
              achieved by two separate interfaces but can be as well be
              achieved with a subclass, e.g:<br>
              - CDI for runtime operations only<br>
              - StartedCDI extends CDI (or CDIContainer or whatever -
              the name does not matter at this point) for runtime
              operations + shutdown.<br>
              <br>
              Normally, CDI is available only. The boot API however
              would return StartedCDI thus allowing a user to shutdown
              what they started.
              <div>
                <div><br>
                  <br>
                  <br>
                  <div>On 03/04/2015 12:24 PM, John D. Ament wrote:<br>
                  </div>
                  <blockquote type="cite">
                    <div dir="ltr">This is actually based on what we
                      discussed in one of the EG meetings
                      <div><br>
                      </div>
                      <div><a href="http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html" target="_blank">http://transcripts.jboss.org/meeting/irc.freenode.org/cdi-dev/2015/cdi-dev.2015-01-14-17.04.log.html</a></div>
                      <div><br>
                      </div>
                      <div>John<br>
                        <br>
                        <div class="gmail_quote">On Wed, Mar 4, 2015 at
                          4:05 AM Jozef Hartinger &lt;<a href="mailto:jharting@redhat.com" target="_blank" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">jharting@redhat.com</a>&gt;
                          wrote:<br>
                          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                            <div text="#000000" bgcolor="#FFFFFF"> Well
                              it&#39;s nowhere given that we must have two
                              separate interfaces for this. We can
                              combine the start/stop API with the
                              existing one to provide an application
                              with a single reference representing the
                              CDI container.</div>
                            <div text="#000000" bgcolor="#FFFFFF"><br>
                              <br>
                              <div>On 02/28/2015 07:05 PM, John D. Ament
                                wrote:<br>
                              </div>
                              <blockquote type="cite">
                                <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" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=rmannibucau@gmail.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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.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" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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(/*
                                        optional<br>
                                        &gt;&gt;&gt; map to configure
                                        vendor features */)) {<br>
                                        &gt;&gt;&gt;     
                                         CDI.current().getBeanManager()....<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.jboss.weld.WeldCdiContainerProvider&quot;).newCDIContainer())<br>
                                        &gt;&gt;&gt; {<br>
                                        &gt;&gt;&gt;     
                                         CDI.current().getBeanManager()....<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())
                                        {<br>
                                        &gt;&gt;&gt;     
                                         container.newInstance(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.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" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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.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" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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).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/cdi/commit/2c362161e18dd521f8e83c27151ddad467a1c01c</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;
                                        _______________________________________________<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" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=cdi-dev@lists.jboss.org&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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/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/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;
                                        _______________________________________________<br>
                                        &gt;&gt;&gt;&gt; cdi-dev mailing
                                        list<br>
                                        &gt;&gt;&gt;&gt; <a href="mailto:cdi-dev@lists.jboss.org" target="_blank" onclick="window.open(&#39;https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=cdi-dev@lists.jboss.org&amp;cc=&amp;bcc=&amp;su=&amp;body=&#39;,&#39;_blank&#39;);return false;">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/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/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>
                              <br>
                            </div>
                          </blockquote>
                        </div>
                      </div>
                    </div>
                  </blockquote>
                  <br>
                </div>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </div></blockquote></div></div></div>