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

Wed Mar 4 07:28:30 EST 2015

ok, initialize was returning a CDI instance then.

If CDI instance is so present why bothering container api with it? Just
looks like another Unmanaged. In this case I would enhance Unmanaged to
have shortcut like create() (shortcut for produce()/inject()/postConstruct()
) and destroy (preDestroy()/dispose()). Said otherwise: the need is already
in the API so why not letting EE getting these enhancement as well?

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 13:09 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:

> Same way as defined in the spec
>
> CDI.current().destroy(..)
>
> On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>> 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.getCDICont
>>>>>>>>> ainer();
>>>>>>>>> >>>> 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/
>>>>>>>>> 2c362161e18dd521f8e83c27151ddad467a1c01c
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> 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/347d70fd/attachment-0001.html 