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

[John D. Ament]

I don't understand the relationship to Java SE mode.

On Wed, Mar 4, 2015 at 7:33 AM Romain Manni-Bucau <rmannibucau at gmail.com>
wrote:

> 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.
>>>>>>>>>>>> WeldCdiContainerProvider").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/dde61280/attachment-0001.html