users@javaee-spec.java.net

[javaee-spec users] [jsr366-experts] Re: updated requirements

From: Jason Greene <jason.greene_at_redhat.com>
Date: Mon, 23 Mar 2015 16:38:20 -0500

While the other discussion is ongoing I thought I would address this one, even though it was written before my other replies:

> On Mar 19, 2015, at 8:21 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
>
> I've tried to coalesce our recent discussion into an updated set of
> requirements. If we can come to agreement on these requirements,
> we'll update the spec accordingly. I've written these in the style
> of RFC 2119, although they'll need to be rewritten to better fit
> into the current style of the spec, and will need to be added to the
> appropriate places in the spec. Right now I'm just trying again to
> make sure we agree on what the requirements *are*. And again, none
> of these are intended to be new requirements, they're intended to
> be clarifications of the existing requirements. If we decided we
> want to strengthen any of these requirements, we would do that for
> Java EE 8.
>
> If you disagree with any of these, let me know what you think they
> *should* say.
>
> If anything is missing based on our recent discussion, please suggest
> additions.
>
> Thanks
>
>
> -----
>
> If annotations are being processed (as required by table EE.10-1,
> Servlet table 8-1, and EJB tables 16 and 17), *at least* all of the
> classes specified in table EE-5.1 MUST be scanned for annotations that
> specify deployment information. As specified in section EE.8.5.2, all
> classes that can be used by the application MAY be scanned for these
> annotations. (These are the annotations that specify information
> equivalent to what can be specified in a deployment descriptor. This
> requirement says nothing about the processing of annotations that were
> defined for other purposes.) These annotations MAY appear on classes,
> methods, and fields.

The approach of explicitly allowing B and C for EE7 is reasonable, since it preserves compatibility for existing implementations.

> 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?
>
> The metadata-complete attribute in the standard deployment descriptors
> effects *only* the scanning of annotations that specify deployment
> information, including web services deployment information. It has no
> impact on the scanning of other annotations.

That’s fine.

>
> The default JNDI namespace for resource reference and definition
> annotations MUST *always* be "java:comp/env". Note that this applies
> to both the case where no name has been supplied so the rules for
> choosing a default name are used, and the case where a name has been
> supplied explicitly but the name does not specify a java: namespace.
> Since the java:comp namespace is not available in some contexts, use of
> that namespace in such a context SHOULD result in a deployment error.
> Likewise, the java:module namespace is not valid in some contexts; use
> of that namespace in such contexts SHOULD result in a deployment
> error.

I really think we should figure out the EE8 strategy for what we are going to do before deciding on this, but I do prefer this over a compatibility breaking MUST. If we do go with the SHOULD language, I think we need to update the CDI spec and examples to use fully qualified namespaces.

>
> All resource references SHOULD be mapped to resources defined in the
> target operational environment. By default, if a resource reference
> is not mapped, deployment MUST fail. A product MAY provide a deployment
> option that allows deployment to succeed in this case.

Thats fine.

>
> Deployment SHOULD fail if the lookup attribute in a resource
> annotation, or the lookup-name element in a deployment descriptor
> entry, does not specify a name with an explicit java: namespace.


Also fine.


>
> Deployment MAY provide an option that controls whether or not an
> application is attempted to be started during deployment. If no such
> option is provided, and deployment is successful, the application MUST
> be started. If the application is attempted to be started during
> deployment, CDI MUST be initialized during deployment. [XXX - need
> reference to exactly what constitutes CDI initialization]. If CDI
> initialization fails, deployment MUST fail. CDI MUST ONLY be
> initialized if the application is attempted to be started. [XXX - need
> to determine whether any other initialization is required]

Would this “start” state be step 3 of E 2.11.4?

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat