Mark Struberg wrote on 03/05/2015 06:06 AM:
>
>> 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…
I didn't expect that to work, because I didn't expect CDI initialization to be
done *before* the container handles all the resource references and decides if
deployment should succeed or not.
> 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…
Clearly if you're starting the application just enough to run the CDI bootstrap,
you need to do that before initializing other parts of the application, such
as @Startup EJBs. And if the application is being deployed without being
started, you need to undo everything that was done by this partial start of
the application and shut it down. Of course, you'll need to redo all this
initialization when the application is started for real, and assume that it
will produce the same results every time.
> 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)?
The whole point of exposing the resource dependencies of an application to
the deployment process through (originally) deployment descriptors was so
that the deployment process could ensure all those dependencies are satisfied
so that the application wouldn't fail at runtime due to an unsatisfied
dependency. If we didn't care about being able to check that at deployment
time, there would've been no need to have this information in the deployment
descriptors. The application could've just done its JNDI lookups (or later,
injections) and hoped that the administrator had configured those resources
properly.