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

[Jozef Hartinger]

Yes, this is one of the options. If we decide to follow this path we 
should be careful not to design the API in a way that would add 
artificial barriers to the multi-container scenario. (E.g. a static 
shutdown() instead of a shutdown() method on a container handle)

On 10/29/2014 12:55 PM, Mark Struberg wrote:
> 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.
>>