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

Wed Mar 4 07:33:38 EST 2015

instead of

 Unmanaged<Foo> unmanagedFoo = new Unmanaged<Foo>(Foo.class);
 UnmanagedInstance<Foo> fooInstance = unmanagedFoo.newInstance();
 Foo foo = fooInstance.produce().inject().postConstruct().get();
 ... // Use the foo instance
 fooInstance.preDestroy().dispose();

just doing

 UnmanagedInstance<Foo> fooInstance = new Unmanaged<Foo>(Foo.class).create();
 ... // Use the foo instance
 fooInstance.destroy();

Would make the main then quite trivial and more user friendly IMO

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

> Get what enhancements?
>
> On Wed, Mar 4, 2015 at 7:28 AM Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>> 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/1e68bc15/attachment-0001.html 