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

[John D. Ament]

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/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/bcbaeed5/attachment-0001.html