[cdi-dev] CDI 2.0 first Face to face meeting feedbac

Mark Struberg struberg at yahoo.de
Wed Oct 29 07:55:55 EDT 2014


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 at redhat.com> 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 at yahoo.de> 
> 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 at gmail.com> 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 at sabot-durand.net> 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 at gmail.com> 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 at 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-meeting-feedback/
>>>>>>> 
>>>>>>> 
>>>>>>>  Regards,
>>>>>>> 
>>>>>>> 
>>>>>>>  Antoine
>>>>>>>  _______________________________________________
>>>>>>>  cdi-dev mailing list
>>>>>>>  cdi-dev at 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 at 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 at 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 at 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.
> 



More information about the cdi-dev mailing list