Re: [cdi-dev] CDI-26 feedback

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

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 ?

Antoine > 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... > > 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 > > 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 <mailto:cdi-dev@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.