[cdi-dev] CDI-26 feedback

Jozef Hartinger jharting at redhat.com
Wed May 27 05:20:50 EDT 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20150527/e0f9ac33/attachment-0001.html 


More information about the cdi-dev mailing list