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

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&gt;: >>>>>>>>> > 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.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(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. >>>>> >>>> >>