Archive for 5月, 2015
Java EE 7 メンテナンス・レビュー・ドラフトの変更リスト一覧
自分用メモ
Java EE 7 Maintenance Review: Proposed Changes
————-
Section EE.5.2.2. [Clarify rules for default namespace.]
Replace the first sentence of the sixth paragraph on p. 69, section
5.2.2, with the following:
The default JNDI namespace for resource references and resource
definitions 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.
———-
Section 5.3.3. [Clarify the requirements for the specification of
the lookup and lookup-name elements.]
Add the following to the end of the second paragraph of section
EE.5.3.3, p. 77:
Deployment should fail if the lookup element of an annotation or the
lookup-name element in a deployment descriptor entry does not specify
a name with an explicit java: namespace.
——————-
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.
——
Sections EE.5.19, EE5.20, EE5.21. [Correct editorial error in third
paragraph of each of these sections to correctly reflect Application
Assembler role.]
In EE.5.19, 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.
In EE.5.20, change:
The Application Component Provider or Deployer may explicitly bind
a JMS ConnectionFactory resource reference to the default
connection factory 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 JMS ConnectionFactory resource reference to the
default connection factory using the lookup element of the Resource
annotation or the lookup-name element of the resource-ref
deployment descriptor element.
In EE.5.21, change:
The Application Component Provider or Deployer may explicitly bind
a resource reference to a default Concurrency Utilities object
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 resource reference to a default Concurrency
Utilities object using the lookup element of the Resource
annotation or the lookup-name element of the resource-ref
deployment descriptor element.
——
Sections EE.5.19.1, EE.5.20.1, EE.5.21.1 [Correct editorial error in
second paragraph of each of these sections to reflect role of
Application Assembler.]
In EE.5.19.1, change:
If a DataSource resource reference is not mapped to a specific data
source by the Application Component Provider or Deployer, it must be
mapped by the Java EE Product Provider to a preconfigured data
source for the Java EE Product Provider’s default database.
to:
If a DataSource resource reference is not mapped to a specific data
source by the Application Component Provider, Application Assembler,
or Deployer, it must be mapped by the Java EE Product Provider to a
preconfigured data source for the Java EE Product Provider’s default
database.
In EE.5.20.1, change:
If a JMS ConnectionFactory resource reference is not mapped to a
specific JMS connection factory by the Application Component
Provider or Deployer, it must be mapped by the Java EE Product
Provider to a preconfigured JMS connection factory for the Java EE
Product Provider’s default JMS provider.
to:
If a JMS ConnectionFactory resource reference is not mapped to a
specific JMS connection factory by the Application Component
Provider, Application Assembler, or Deployer, it must be mapped by
the Java EE Product Provider to a preconfigured JMS connection
factory for the Java EE Product Provider’s default JMS provider.
In EE.5.21.1, change:
If a Concurrency Utilities object resource environment reference is
not mapped to a specific configured object by the Application
Component Provider or Deployer, it must be mapped by the Java EE
Product Provider to a preconfigured Concurrency Utilities object for
the Java EE Product Provider.
to:
If a Concurrency Utilities object resource environment reference is
not mapped to a specific configured object by the Application
Component Provider, Application Assembler, or Deployer, it must be
mapped by the Java EE Product Provider to a preconfigured
Concurrency Utilities object for the Java EE Product Provider.
——
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 resource reference should be bound to a resource of the
required type.
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 Java EE product is not required to support permissions.xml
files that specify permission 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.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. [Clarify the rules regarding whether an application
is attempted to be started during deployment].
Replace the first full paragraph on p. 215 with the following:
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 or if the option to start the application is
specified, and if deployment is successful, the application modules
must be initialized as specified in section EE.8.5.4 and the
application must be started.
If the application is attempted to be started during deployment, the
Servlet and EJB containers must be initialized during deployment.
Such initialization must include CDI initialization. If
initialization fails, deployment must fail.
If the application is not attempted to be started during deployment,
these containers must not be initialized during deployment.
In all cases, the deployment and initialization of a Java EE
application must be complete before the container delivers client
requests to any of the application’s components. The container must
first initialize all startup-time singleton session bean components
before delivering any requests to enterprise bean
components. Containers must deliver requests to web components and
resource adapters only after initialization of the component has
completed.
——
Section EE.8.5. [Clarify the requirements for annotation scanning and
processing.]
Replace the *first* paragraph of section EE.8.5 on p. 216 with the
following pragraphs (i.e., break it up as follows and include
the new text):
Some deployment descriptors are optional. The required deployment
information is determined by using default rules or by annotations
present on application class files. Some deployment descriptors that
are included in an application may exist in either complete or
incomplete form. A complete deployment descriptor provides a complete
description of the deployment information; a deployment tool must not
examine class files for this deployment information. An incomplete
deployment descriptor provides only a subset of the required
deployment information; a deployment tool must examine the application
class files for annotations that specify deployment information.
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 optionally 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. 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.
Any deployment information specified in a deployment descriptor
overrides any deployment information specified in an application’s
class files. The Java EE component specifications, including this
specification, describe when deployment descriptors are optional and
which deployment descriptors may exist in either complete or
incomplete form. The attribute metadata-complete is used in the
deployment descriptor to specify whether the descriptor is complete.
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.
——
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.]
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.
——-
Figures EE.8-3, EE.10-1 [Corrected inconsistencies with the XML
schemas.]
Replace “connector-resource*” with “connection-factory*” in
Figures EE.8-3 and EE.10-1.
Add “administered-object*” to Figure EE.10-1.
寺田 佳央 - Yoshio Terada 