Java EE 7 Maintenance Review

Proposed Changes:

------

Section EE.5.2.2  [Clarify that annotations occurring on classes
outside a web module or ejb module must specify JNDI names in the
java:app or java:global namespace.]

Change the last paragraph on page 69 from:
  An environment entry declared in the application.xml descriptor must
  specify a JNDI name in the java:app or java:global namespace, for
  example: java:app/env/myString or java:global/someValue.
to:
  An environment entry declared in the application.xml descriptor or
  by an annotation on a class in the application package other than
  within a web module or EJB module must specify a JNDI name in the
  java:app or java:global namespace, for example:
  java:app/env/myString or java:global/someValue.

------

Sections EE.5.2.5, EE.5.18, EE.5.18.3, EE.5.18.4, EE.5.18.5,
EE.5.18.6, EE.5.18.7, EE.5.18.8  [Clarify that resource annotations 
may appear on any class in the application package.]

Section EE.5.2.5 
Change the text starting on line 3 on page 74 from:
   Resource annotations may appear on any of the classes listed above, 
   or on any superclass of any class listed above.
to:
   Resource annotations may appear on any class in the application package.

Section EE.5.18
Add the following text to the end of paragraph 2 of page 129 
(the paragraph starting "The following annotations..."):
  Resource definition annotations may appear on any class in the 
  application package.

Section EE.5.18.3
Change the following text on page 132:
   A DataSource resource may also be defined using the
   DataSourceDefinition annotation on a container-managed class, such
   as a servlet or enterprise bean class.
to:
   A DataSource resource may also be defined using the
   DataSourceDefinition annotation on any class in the application
   package.

Section EE.5.18.4 
Change the following text on page 135:
    A JMS ConnectionFactory resource may also be defined using the
    JMSConnectionFactoryDefinition annotation on a container-managed
    class, such as a servlet or enterprise bean class.
to:
    JMS ConnectionFactory resource may also be defined using the 
    JMSConnectionFactoryDefinition annotation on any class in the 
    application package.

Section EE.5.18.5 
Change the following text on page 137:
    "A JMS Destination resource may also be defined using the
    JMSDestinationDefinition annotation on a container-managed class,
    such as a servlet or enterprise bean class."
to:
    "A JMS Destination resource may also be defined using the
    JMSDestinationDefinition annotation on any class in the
    application package."

Section EE.5.18.6
Change the following text on page 139:
     A Mail Session resource may also be defined using the
     MailSessionDefinition annotation on a container-managed class,
     such as a servlet or enterprise bean class.
to:
     A Mail Session resource may also be defined using the
     MailSessionDefinition annotation on any class in the application
     package.

Section EE.5.18.7
Change the following text on page 141:
    A Connector connection factory resource may also be defined using
    the ConnectionFactoryDefinition annotation on a container-managed
    class, such as a servlet or enterprise bean class.
to:
    A Connector connection Factory resource may also be defined using
    the ConnectionFactoryDefinition annotation on any class in the
    application package.

Section EE.5.18.8
Change the following text on page 143:
    "An administered object resource may also be defined using the
    AdministeredObjectDefinition annotation on a container-managed
    class, such as a servlet or enterprise bean class."
to:
    "An administered object resource may also be defined using the 
    AdministeredObjectDefinition annotation on any class in the 
    application package."

------

Section EE.5.18.6.1 [Correct editorial error in the second paragraph]

Change the following text on page 140:
    If a mail session resource has been previously provisioned for the
    application (e.g., by administrative action), it is the
    responsibility of the Application Component Provider to specify
    the mail server host name.
to:
    If a mail server resource has been previously provisioned for the
    application (e.g., by administrative action), it is the
    responsibility of the Application Component Provider to specify
    the mail server host name.

------

Section EE.5.19. [Correct editorial error in third paragraph.]

Change:
   The Application Component Provider or Deployer may explicitly bind
   a DataSource resource reference to the default data source using
   the lookup element of the Resource annotation or the lookup-name
   element of the resource-ref deployment descriptor element.
to:
   The Application Component Provider or Application Assembler may
   explicitly bind a DataSource resource reference to the default data
   source using the lookup element of the Resource annotation or the
   lookup-name element of the resource-ref deployment descriptor
   element.

------

Sections EE.8.1.3., EE.5.19, EE.5.20, EE.5.21, EE.5.3.3.
[Clarify the rules for the binding of unmapped resources.]

In EE.8.1.3, add the following new paragraphs:

   Every reference to an external resource must be bound to a resource
   of the required type that exists in the target operational
   environment.  The binding may be done using any product-specific
   mapping or binding capability or rules.  By default, if a required
   resource is not present in the target operational environment,
   deployment must fail.  A product may provide an option that allows
   deployment to succeed even though required resources are missing,
   although this is discouraged because it can lead to unexpected
   runtime failures.

   Some resources have default mapping rules specified; see sections
   EE.5.19, EE.5.20, and EE.5.21.  By default, a product must map
   otherwise unmapped resources using these default rules.  A product
   may include an option to disable or override these default mapping
   rules.

   Once a resource reference is bound to a resource in the target
   operational environment, and deployment succeeds, that binding is
   not expected to change.  A product may provide administrative
   operations that change the resource bindings that are used by
   applications.  A product may notify applications of changes to
   their resource bindings using JNDI events, but this is not
   required.

   If deployment succeeds, in addition to binding resource references
   as specified above, every resource definition (see Section EE.5.18)
   specified by the application or specified or overridden by
   the deployer must be present in the target operational environment.

In EE.5.19, change the following text:
         In the absence of such a binding, the mapping of the
         reference will default to the product's default data source.
to:
         In the absence of such a binding, or an equivalent
         product-specific binding, the mapping of the reference will
         default to the product's default data source.

In EE.5.20, change the following text:
         In the absence of such a binding, the mapping of the
         reference will default to a JMS connection factory for the
         product's JMS provider.
to: 
         In the absence of such a binding, or an equivalent
         product-specific binding, the mapping of the reference will
         default to a JMS connection factory for the product's JMS
         provider.

In EE.5.21, change the following text:
         In the absence of such a binding, the mapping of the
         reference will default to the product's default managed
         executor service.
to:
         In the absence of such a binding, or an equivalent
         product-specific binding, the mapping of the reference will
         default to the product's default managed executor service.


In section EE.5.3.3, add the following to the end of the second paragraph:
         The Deployer may also use product-specific resource mapping
         tools, deployment descriptors, rules, or capabilities to
         bind resource reference entries to resources in the target
         operational environment.

------

Section EE.6.2.2.6 [Clarify requirements for support of custom
permissions]:

Add the following to the end of paragraph 3:
   The product is not required to support the use in the 
   permissions.xml file of permissions classes that are packaged
   in the application.

------

Section EE.6.7.  [In the list in paragraph 3, correct the interface
shown for the third and fourth items.  This should be
javax.jms.JMSConsumer, not javax.jms.JMSContext].

Replace:
  javax.jms.JMSContext method getMessageListener
with
  javax.jms.JMSConsumer method getMessageListener

Replace:
  javax.jms.JMSContext method setMessageListener
with
  javax.jms.JMSConsumer method setMessageListener

------

Section EE.6.7. [In the list in paragraph 3, add missing methods for
 consistency with JMS spec.]

Add:
javax.jms.JMSContext createContext
javax.jms.JMSProducer setAsync 
javax.jms.MessageProducer send(Message message, CompletionListener completionListener)
javax.jms.MessageProducer send(Message message, int deliveryMode, int priority, long timeToLive,
CompletionListener completionListener)
javax.jms.MessageProducer send(Destination destination, Message message,
CompletionListener completionListener)
javax.jms.MessageProducer send(Destination destination, Message message, int deliveryMode, int priority, long timeToLive, CompletionListener completionListener)

------

Section EE.8.5.2.  [Clarify the intended semantics by correcting the
ambiguity resulting from the use of "JAR" to refer to both modules and
.jar files referenced from modules.]

Change EE.8.5.2 item 1.d on page 218) from:

d.For all files in the application package with a filename extension
of .jar, but not contained in the lib directory, do the following:

   i. If the JAR file contains a META-INF/MANIFEST.MF file with a
   Main-Class attribute, or contains a META-INF/application-client.xml
   file, consider the JAR file to be an application client module.

   ii. If the JAR file contains a META-INF/ejb-jar.xml file, or
   contains any class with an EJB component-defining annotation
   (Stateless, etc.), consider the JAR file to be an EJB module.

   iii. All other JAR files are ignored unless referenced by a JAR
   file discovered above using one of the JAR file reference
   mechanisms such as the Class-Path header in a manifest file.

to:

d.For all files in the application package with a filename extension
of .jar, but not contained in the lib directory, do the following:

   i. If the .jar file contains a META-INF/MANIFEST.MF file with a
   Main-Class attribute, or contains a META-INF/application-client.xml
   file, consider the .jar file to be an application client module.

   ii. If the .jar file contains a META-INF/ejb-jar.xml file, or
   contains any class with an EJB component-defining annotation
   (Stateless, etc.), consider the .jar file to be an EJB module.

   iii. All other .jar files are ignored unless referenced by a JAR
   file discovered above using one of the JAR file reference
   mechanisms such as the Class-Path header in a manifest file.

------

Section EE.10.6 [Correct table to include missing entries for
application-client_6 and application-client_7.  These should
be the same as for application-client_5, namely: No->Yes, Yes->No]

Add the following entries to Table EE.10-1:
   application-client_6    Yes    No
   application-client_7    Yes    No

Add the following to the paragraph above this table:
   Whether or not to process annotations depends on the
   presence and version of the deployment descriptor and
   the setting of the metadata-complete attribute.