<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Well it'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.<br>
    <br>
    <div class="moz-cite-prefix">On 02/28/2015 07:05 PM, John D. Ament
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAOqetn8Ht5YuW_aN8jLX2_-PV3Fr1mg6rynktOvEBNGRFLDafA@mail.gmail.com"
      type="cite">
      <div dir="ltr">Maybe I'm misreading, but I don't see us adding
        another API to do the same thing here - we'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 moz-do-not-send="true"
              href="mailto:rmannibucau@gmail.com">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 moz-do-not-send="true" href="http://www.tomitribe.com"
                target="_blank">http://www.tomitribe.com</a><br>
              <a moz-do-not-send="true"
                href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
              <a moz-do-not-send="true"
                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
                moz-do-not-send="true" href="mailto:jharting@redhat.com"
                target="_blank"
                onclick="window.open('https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=','_blank');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, "Jozef Hartinger" &lt;<a
                moz-do-not-send="true" href="mailto:jharting@redhat.com"
                target="_blank"
                onclick="window.open('https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=','_blank');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("org.jboss.weld.WeldCdiContainerProvider").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 moz-do-not-send="true"
                href="http://www.tomitribe.com" target="_blank">http://www.tomitribe.com</a><br>
              &gt;&gt;&gt; <a moz-do-not-send="true"
                href="http://rmannibucau.wordpress.com" target="_blank">http://rmannibucau.wordpress.com</a><br>
              &gt;&gt;&gt; <a moz-do-not-send="true"
                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 moz-do-not-send="true"
                href="mailto:jharting@redhat.com" target="_blank"
                onclick="window.open('https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=','_blank');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's "smart<br>
              &gt;&gt;&gt;&gt; sorting"<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 moz-do-not-send="true"
                href="mailto:jharting@redhat.com" target="_blank"
                onclick="window.open('https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=','_blank');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'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'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'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'm not disagreeing.  There's a few
              things I'd consider:<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; - Is this mostly for new apps or
              existing?  If existing, it'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'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'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'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'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'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'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's not even a way to get a reference
              to it that I'm aware of.  It's<br>
              &gt;&gt;&gt;&gt; used by the implementor only.<br>
              &gt;&gt;&gt;&gt;<br>
              &gt;&gt;&gt;&gt; I don't think there'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 moz-do-not-send="true"
                href="mailto:jharting@redhat.com" target="_blank"
                onclick="window.open('https://mail.google.com/mail/?view=cm&amp;tf=1&amp;to=jharting@redhat.com&amp;cc=&amp;bcc=&amp;su=&amp;body=','_blank');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 "params" 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'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'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 moz-do-not-send="true"
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 moz-do-not-send="true"
                href="mailto:cdi-dev@lists.jboss.org" target="_blank"
                onclick="window.open('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=','_blank');return
                false;">cdi-dev@lists.jboss.org</a><br>
              &gt;&gt;&gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                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 moz-do-not-send="true"
                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 moz-do-not-send="true"
                href="mailto:cdi-dev@lists.jboss.org" target="_blank"
                onclick="window.open('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=','_blank');return
                false;">cdi-dev@lists.jboss.org</a><br>
              &gt;&gt;&gt;&gt; <a moz-do-not-send="true"
                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 moz-do-not-send="true"
                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>
  </body>
</html>