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

I don't understand the relationship to Java SE mode. On Wed, Mar 4, 2015 at 7:33 AM Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; 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(a)gmail.com&gt;: > >> Get what enhancements? >> >> On Wed, Mar 4, 2015 at 7:28 AM Romain Manni-Bucau <rmannibucau(a)gmail.com&gt; >> 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(a)gmail.com&gt;: >>> >>>> Same way as defined in the spec >>>> >>>> CDI.current().destroy(..) >>>> >>>> On Wed, Mar 4, 2015 at 6:44 AM Romain Manni-Bucau < >>>> rmannibucau(a)gmail.com&gt; 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(a)gmail.com&gt;: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Mar 4, 2015 at 6:35 AM Romain Manni-Bucau < >>>>>> rmannibucau(a)gmail.com&gt; wrote: >>>>>> >>>>>>> 2015-03-04 12:29 GMT+01:00 John D. Ament <john.d.ament(a)gmail.com&gt;: >>>>>>> >>>>>>>> Hmm.. comments in line. >>>>>>>> >>>>>>>> On Wed, Mar 4, 2015 at 4:49 AM Antoine Sabot-Durand < >>>>>>>> antoine(a)sabot-durand.net&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; 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(a)gmail.com&gt; >>>>>>>>>> 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(a)gmail.com&gt; 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(a)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(a)redhat.com&gt; 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(a)redhat.com&gt;: >>>>>>>>>>>> >>>> >>>>>>>>>>>> >>>> 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(a)redhat.com&gt; >>>>>>>>>>>> >>>> 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(a)redhat.com&gt; >>>>>>>>>>>> >>>>> 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(a)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(a)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(a)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(a)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. >>>>>>>> >>>>>>> >>>>> >>> >