> On Mar 24, 2015, at 2:00 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
> Jason Greene wrote on 03/24/15 10:21:
>>>>> All resources specified by resource definition annotations MUST be
>>>>> created. All resource reference annotations MUST result in JNDI entries
>>>>> in the corresponding namespace.
>>>>
>>>> This seems to contradict the weaker SHOULD language in the paragraph on
>>>> defaults below?
>>>
>>> I guess the question is, if you use java:comp where it's not valid, and you
>>> *don't* fail deployment in that case, what's allowed to happen?
>>>
>>> Ignoring the annotation would be fine, and probably the second best
>>> choice.
>>>
>>> Creating the annotation in some product-specific java:comp namespace
>>> associated with some product-defined "component" would also be fine.
>>
>> I agree both of those should be fine.
>
> Do you think I need to rewrite the above to incorporate this?
> Do I need to list the allowed alternatives? The intent was to
> allow at least those, but not necessarily constrain what non-portable
> behavior is allowed.
No I think your original wording is clear, in particular when combined with my suggestion below. So in total:
"All resources specified by resource definition annotations MUST be
created. All resource reference annotations MUST result in JNDI entries
in the corresponding namespace. If the corresponding namespace
is not available to the class declaring or inheriting the reference,
the resulting behavior is undefined. Future versions of this specification
may alter this behavior.”
-snip-
>>
>> Ok. So I think the reference you want is 12.2:
>>
>> " If the application is attempted to be started during deployment, the
>> startup initialization procedure defined by the relevant Java EE component
>> specifications must be executed during deployment. Notably, CDI MUST be
>> initialized during deployment, in accordance with "12.2 Application
>> initialization lifecycle" of the CDI specification. Failure of application
>> startup during deployment MUST also abort the deployment. If the application
>> is not started during deployment, then the startup initialization procedure
>> defined by relevant Java EE component specifications MUST not be executed.”
>
> 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.
>
>> 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.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat