Le 27 mai 2015 à 14:57, John D. Ament <john.d.ament(a)gmail.com&gt; 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.

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.

John On Wed, May 27, 2015 at 5:21 AM Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@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/a112489f248ab9074da4d0a81a28abc67... <https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67... 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(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. _______________________________________________ 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.

Le 27 mai 2015 à 14:57, John D. Ament <john.d.ament(a)gmail.com&gt; 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. 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. John On Wed, May 27, 2015 at 5:21 AM Jozef Hartinger <jharting(a)redhat.com <mailto:jharting@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/a112489f248ab9074da4d0a81a28abc67... <https://github.com/johnament/cdi/commit/a112489f248ab9074da4d0a81a28abc67... 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(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. _______________________________________________ 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.