> Am 05.03.2015 um 02:04 schrieb Bill Shannon <bill.shannon_at_oracle.com>:
>
> This is mostly an issue of how portable extensions can influence what's
> considered a CDI bean, right? Are there other aspects we need to define?
In beans.xml you can have different bean-discovery-modes (CDI section 12.1, 2.5, 12.4).
You can e.g. define bean-discovery-mode=annotated and then all classes which have no ‚bean defining annotation‘ (section 2.5.1) will simply not get scanned and thus not get picked up as CDI beans. If those have Resource injections then the CDI container will not handle them.
The same applies if some class/package is explicitly <exclude>d from scanning via beans.xml (section 12.4.2).
Of course CDI Extension can do other tricky things as well. E.g. they can add random annotations - @Resource amongst them - to any class. Should those account for registration in the EE resource ecosystem? I’m not sure myself if it is expected to work…
Oh and all the CDI stuff basically needs a bootstrap of the application. You might shut it down immediately after that but I’m not sure if this works in practice. E.g. if the container start start up quartz or some @Startup EJBs, etc…
For me the question is more: do we _really_ need to know all resource providers and consumers even if those apps are not started? What if I deploy multiple versions of my application on the same box (in the intention to only have one running at any given time)?
LieGrue,
strub