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

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.getCDIContainer(); >>>>>> >>>> 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. >> >