<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 class="gmail_signature"><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">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 class="h5"><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">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">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">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(/* 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">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.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).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">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">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>