[jsr366-experts] Re: updated requirements

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Tue, 31 Mar 2015 15:25:57 -0700

Catching up on a few remaining threads in this conversation...

Jason Greene wrote on 03/24/15 12:42:
>> There's a lot of other "application initialization" that's done during
>> application startup. I'm not convinced that all of it, or in fact any of
>> it except CDI initialization, can currently cause application deployment to
>> fail. I'm still trying to get answers to what the RI does.
> Web sockets can as well:
> 5.2.1 "In both cases, a deployment error raised during the deployment process
> must halt the deployment of the application,"
> ...
> "If the deployment error occurs while deployment is managed by the
> implementation, for example, as a result of deploying a WAR file where the
> endpoints are deployed by the container as a result of scanning the WAR file,
> the deployment error must be reported to the deployer by the implementation
> as part of the container specific deployment process.”
> I don’t recall if any of the other specifications have something like this.

The more I look into this, the more surprised I am with how much is
unspecified. :-(

Apparently there are many things that happen during Servlet container
initialization, and if those things fail, the Servlet container initialization
fails, and the application deployment fails. For example, failure of a
ServletContainerInitializer will cause deployment to fail, which is how
the WebSocket requirements above are implemented (I believe).

>>> If desired we could include a non-normative:
>>> “Since startup initialization is deferred, errors during that occur
>>> during this process are also deferred. Therefore, the deployment process
>>> may succeed in spite of such errors."
>> Yes, a warning of this sort is probably appropriate.
>> One of the things that worries me is that this creates a conflict between
>> the requirement to detect all missing resources during deployment, and the
>> need to run the CDI bootstrap in order to find all the resource
>> references. As I keep saying, if the resource references were discovered
>> without the help of CDI (i.e., by just examining all the classes), this
>> wouldn't be an issue.
>> If you deploy an app without starting it, and you depend on running the
>> CDI bootstrap to find all the references, missing resource references
>> might not be detected at deployment time. If you detect them during
>> application startup, must the application fail to start? And does it
>> depend on whether you deployed with the option to ignore missing resource
>> references?
> We could just clarify the CDI spec to say that portable extensions which add
> non-CDI annotations has undefined behavior, and then in EE8 explicitly
> disallow it.

That's probably wise.

Also, application clients throw a wrench into much of this.

Application clients *can't* be initialized during deployment, yet they can
define and reference resources. There's no way for CDI to influence the
resources of an application client; by the time CDI is initialized for the
application client, it's too late. You can't depend on CDI to tell you
what the managed beans are in an application client, so you have to scan
all the classes of the application client.

Decoupling the resource declarations of an application from CDI seems like
the only way to make it work.