[cdi-dev] CDI-26 feedback

Thu May 28 02:21:14 EDT 2015


On 05/27/2015 03:34 PM, Antoine Sabot-Durand wrote:
>
>> Le 27 mai 2015 à 14:57, John D. Ament <john.d.ament at gmail.com 
>> <mailto:john.d.ament at gmail.com>> a écrit :
>>
>> Jozef,
>>
>> Neither was lost, just not in scope for us to get EDR1 out the door.
>>
>> 1. Antoine just now raised a separate issue.
>
> Perhaps we should state in EDR (in a side note) that it will be 
> addressed later and ask for user input. Wdyt?
>
> Now if there are real issues in producing a EDR1 simple with all 
> discovery mode we could restrict the bean discovery mode by supporting 
> only “none” for the EDR1 (side note again).
It's neither "all" nor "none" discovery modes that I am concerned about. 
It' implicit bean archives with no beans.xml that are problematic.
>
> I understand that it’s not totally satisfying to not be able to 
> release all the feature at once, but let’s face it, CDI-26 has been 
> around for 4,5 years so splitting it in smaller part to resolve them 
> one by one seems the best solution to get out Java SE support.
>
>>
>> 2. EDR1 infers that only a single CDI instance is associated to a 
>> CDIProvider (so they're 1:1).  We can move this after EDR1.
>
> Unless Jozef has a proposal to solve the issue for getCdi() and that 
> we all agree on.
>
> In the other case I will add a ticket for the multiple container 
> support in SE. That could even be wise since it’s a controversial 
> feature (Mark is against it), so having a specific place to discuss it 
> could be a better solution.
>
> Jozef, any thought about this ?
Sounds good to me.
>
> Antoine
>
>
>> John
>>
>> On Wed, May 27, 2015 at 5:21 AM Jozef Hartinger <jharting at redhat.com 
>> <mailto:jharting at redhat.com>> wrote:
>>
>>     Hi all,
>>
>>     I'd like to raise several concerns with the CDI-26 resolution
>>     that I either forgot to raise before or were lost in the process.
>>
>>     1) Bean discovery in SE
>>
>>     I was under the impression that the task to define bean discovery
>>     for SE was postponed post EDR1 yet the PR for CDI-26 that has
>>     been merged defines bean discovery in SE explicitly
>>     https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67f8cdbe5#diff-ffe540480772deae967ea309fa5f3976R44
>>
>>     I am concerned about the way it is defined currently as it
>>     requires that the CDI implementation eagerly loads/scans each and
>>     every class found on the classpath during initialization. Due to
>>     performance implications of this I am convinced that this is not
>>     the desired behavior. It may be useful to support this for some
>>     use-cases with e.g. a special container mode but I doubt this
>>     should be the default behavior for CDI in SE. Let's not forget to
>>     fix this.
>>
>>     2) CDIProvider.isInitialized()
>>
>>     First of all, good job on removing the constraints, preventing
>>     multiple parallel container support, from the API. One missing
>>     piece seems to be CDIProvider.isInitialized(). The JavaDoc says:
>>     " Determines whether or not this CDIProvider has been initialized
>>     or not"
>>
>>     My understanding is that it is supposed to indicate whether a CDI
>>     object is in initialized state yet or whether it has been shut
>>     down. If my understanding is correct then this method should
>>     probably be moved to the CDI class instead. Due to the possible
>>     1-to-n mapping between CDI and CDIProvider it's not correct to
>>     have this method on CDIProvider
>>
>>     Jozef
>>     _______________________________________________
>>     cdi-dev mailing list
>>     cdi-dev at lists.jboss.org <mailto: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 <mailto: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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150528/0248f5a7/attachment-0001.html