Le 23 oct. 2014 à 03:13, John D. Ament <john.d.ament(a)gmail.com&gt; a écrit : Hi Antoine, For the SE feature, I think the return type on the initialize() methods should be CDI instead of BeanManager. What do you think? John On Wed, Oct 22, 2014 at 6:55 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net <mailto:antoine@sabot-durand.net>> wrote: Hi guys, New post on the blog : Check what was discussed in our last week F2F meeting. http://www.cdi-spec.org/news/2014/10/20/CDI-2_0-first-face-to-face-meetin... <http://www.cdi-spec.org/news/2014/10/20/CDI-2_0-first-face-to-face-meetin... Regards, Antoine _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/cdi-dev <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 <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.

I could see this being problematic for implementations to deal with: ContainerBoot boot = ...; BeanManager beanManager1 = boot.initialize(); CDI.current(); BeanManager beanManager2 = boot.initialize(); CDI.current(); I see the second call to CDI.current() failing, since it should end up bound to a thread. If we instead return back a reference to CDI here, we know which instance we're dealing with and avoid the underlying threading problem. John On Thu, Oct 23, 2014 at 5:51 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: What would be the interest of having CDI object to call getBeanManager() instead of having the bean manager directly ? > > >Antoine > >Le 23 oct. 2014 à 03:13, John D. Ament <john.d.ament(a)gmail.com&gt; a écrit : >> >> >>Hi Antoine, >> >> >>For the SE feature, I think the return type on the initialize() methods should be CDI instead of BeanManager. What do you think? >> >> >>John >> >> >>On Wed, Oct 22, 2014 at 6:55 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: >> >>Hi guys, >>> >>> >>> >>> >>>New post on the blog : Check what was discussed in our last week F2F meeting. >>> >>> >>>http://www.cdi-spec.org/news/2014/10/20/CDI-2_0-first-face-to-face-meeting-feedback/ >>> >>> >>>Regards, >>> >>> >>>Antoine >>>_______________________________________________ >>>cdi-dev mailing list &gt;&gt;&gt;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.

> On 23 Oct 2014, at 16:11, Mark Struberg <struberg(a)yahoo.de&gt; wrote: > > I think the only sane thing is to give guarantees for exactly 1 BeanManager at the same time in a JVM. +1 from me, though we should word it that people can do other things if they want to. > Supporting multiple BeanManagers could be done by wiring up an own ClassLoader hierarchy pretty easily. But I have not yet seen any requirement to do so in any productive project so far. > > > And changing impls to support the requirement to support different active BeanManagers on the same Thread is a task for really freaky minds... > > LieGrue, > strub > > > > On Thursday, 23 October 2014, 13:39, John D. Ament <john.d.ament(a)gmail.com&gt; wrote: > > >> >> I could see this being problematic for implementations to deal with: >> >> >> ContainerBoot boot = ...; >> BeanManager beanManager1 = boot.initialize(); >> CDI.current(); >> BeanManager beanManager2 = boot.initialize(); >> CDI.current(); >> >> >> I see the second call to CDI.current() failing, since it should end up bound to a thread. If we instead return back a reference to CDI here, we know which instance we're dealing with and avoid the underlying threading problem. >> >> >> John >> >> >> On Thu, Oct 23, 2014 at 5:51 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: >> >> What would be the interest of having CDI object to call getBeanManager() instead of having the bean manager directly ? >>> >>> Antoine >>> >>> Le 23 oct. 2014 à 03:13, John D. Ament <john.d.ament(a)gmail.com&gt; a écrit : >>>> >>>> Hi Antoine, >>>> >>>> >>>> For the SE feature, I think the return type on the initialize() methods should be CDI instead of BeanManager. What do you think? >>>> >>>> >>>> John >>>> >>>> >>>> On Wed, Oct 22, 2014 at 6:55 AM, Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; wrote: >>>> >>>> Hi guys, >>>>> >>>>> >>>>> >>>>> New post on the blog : Check what was discussed in our last week F2F meeting. >>>>> >>>>> >>>>> http://www.cdi-spec.org/news/2014/10/20/CDI-2_0-first-face-to-face-meetin... >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Antoine >>>>> _______________________________________________ >>>>> 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.

Hi Jozef, just to make sure we are talking about the same thing. I was not talking about adding a validation that maximum a single container can be run at the same time. This was more intended as we should not _require_ implementations to support multiple containers at the same time. It would be o if a CDI ipml blows up or if you get Exceptions when starting multiple CDI containers in the same JVM. But other impls might support this scenario. I'd define this as non-portable if anything. LieGrue, strub > On Wednesday, 29 October 2014, 12:04, Jozef Hartinger <jharting(a)redhat.com&gt; wrote: >> CDI.current() is the only problematic bit. Otherwise, there is no reason > why running multiple CDI containers at the same time should be > prohibited. I think we could limit CDI.current() usage in > multi-container environments and say that a CDI instance obtained from > boot.initialize() should be used instead of using CDI.current(). > > On 10/24/2014 12:15 PM, Pete Muir wrote: >>> On 23 Oct 2014, at 16:11, Mark Struberg <struberg(a)yahoo.de&gt; > wrote: >>> I think the only sane thing is to give guarantees for exactly 1 > BeanManager at the same time in a JVM. >> +1 from me, though we should word it that people can do other things if > they want to. >>> Supporting multiple BeanManagers could be done by wiring up an own > ClassLoader hierarchy pretty easily. But I have not yet seen any requirement to > do so in any productive project so far. >>> >>> And changing impls to support the requirement to support different > active BeanManagers on the same Thread is a task for really freaky minds... >>> LieGrue, >>> strub >>> >>> >>> >>> On Thursday, 23 October 2014, 13:39, John D. Ament > <john.d.ament(a)gmail.com&gt; wrote: >>> >>>> I could see this being problematic for implementations to deal > with: >>>> >>>> ContainerBoot boot = ...; >>>> BeanManager beanManager1 = boot.initialize(); >>>> CDI.current(); >>>> BeanManager beanManager2 = boot.initialize(); >>>> CDI.current(); >>>> >>>> >>>> I see the second call to CDI.current() failing, since it should end > up bound to a thread. If we instead return back a reference to CDI here, we > know which instance we're dealing with and avoid the underlying threading > problem. >>>> >>>> John >>>> >>>> >>>> On Thu, Oct 23, 2014 at 5:51 AM, Antoine Sabot-Durand > <antoine(a)sabot-durand.net&gt; wrote: >>>> What would be the interest of having CDI object to call > getBeanManager() instead of having the bean manager directly ? >>>>> Antoine >>>>> >>>>> Le 23 oct. 2014 à 03:13, John D. Ament > <john.d.ament(a)gmail.com&gt; a écrit : >>>>>> Hi Antoine, >>>>>> >>>>>> >>>>>> For the SE feature, I think the return type on the > initialize() methods should be CDI instead of BeanManager. What do you think? >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> On Wed, Oct 22, 2014 at 6:55 AM, Antoine Sabot-Durand > <antoine(a)sabot-durand.net&gt; wrote: >>>>>> Hi guys, >>>>>>> >>>>>>> >>>>>>> New post on the blog : Check what was discussed in our > last week F2F meeting. >>>>>>> >>>>>>> > http://www.cdi-spec.org/news/2014/10/20/CDI-2_0-first-face-to-face-meetin... >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> >>>>>>> Antoine >>>>>>> _______________________________________________ >>>>>>> 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. >