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. All resources specified by resource definition
annotations MUST be created. All resource reference annotations MUST
result in JNDI entries in the corresponding namespace.
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.
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.
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.
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.
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]