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

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 >>>>>>> >: >>>>>>> >>>> >>>>>>> >>>> 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/2c362161e18dd521f8e8 >>>>>>> 3c27151ddad467a1c01c >>>>>>> >>>>>> >>>>>>> >>>>>> 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. >>> >>