[cdi-dev] Feedback - CDI bootstrap API (CDI-26)

[Romain Manni-Bucau]

hmm, and if the bean is @Dependent? how do you release it?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-03-04 12:37 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:

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