|
Procedure for Java Platform, Enterprise Edition 8 Web Profile Certification |
| Previous | Next | Contents |
This chapter describes the compatibility testing procedure and compatibility requirements for Java Platform, Enterprise Edition 8.
This chapter contains the following sections:
The certification process for Java Platform, Enterprise Edition Version 8 consists of the following activities:
Install the appropriate version of the Technology Compatibility Kit (TCK) and execute it in accordance with the instructions in this User’s Guide.
Ensure that you meet the requirements outlined in ”Compatibility Requirements,” below.
Certify to the Java Partner organization that you have finished testing and that you meet all of the compatibility requirements.
The compatibility requirements for Java Platform, Enterprise Edition Version 8 consist of meeting the requirements set forth by the rules and associated definitions contained in this section.
These definitions are for use only with these compatibility requirements and are not intended for any other purpose.
Table 3-1 Definitions
| Term | Definition |
|---|---|
API Definition Product |
A Product for which the only Java class files contained in the product are those corresponding to the application programming interfaces defined by the Specifications, and which is intended only as a means for formally specifying the application programming interfaces defined by the Specifications. |
Application |
A collection of components contained in a single application package (such as an EAR file or JAR file) and deployed at the same time using a Deployment Tool. |
Computational Resource |
A piece of hardware or software that may vary in quantity, existence, or version, which may be required to exist in a minimum quantity and/or at a specific or minimum revision level so as to satisfy the requirements of the Test Suite. Examples of computational resources that may vary in quantity are RAM and file descriptors. Examples of computational resources that may vary in existence (that is, may or may not exist) are graphics cards and device drivers. Examples of computational resources that may vary in version are operating systems and device drivers. |
Configuration Descriptor |
Any file whose format is well defined by a specification and which contains configuration information for a set of Java classes, archive, or other feature defined in the specification. |
Conformance Tests |
All tests in the Test Suite for an indicated Technology Under Test, as distributed by the Maintenance Lead, excluding those tests on the Exclude List for the Technology Under Test. |
Container |
An implementation of the associated Libraries, as specified in the Specifications, and a version of a Java Platform, Standard Edition Runtime Product, as specified in the Specifications, or a later version of a Java Platform, Standard Edition Runtime Product that also meets these compatibility requirements. |
Deployment Tool |
A tool used to deploy applications or components in a Product, as described in the Specifications. |
Documented |
Made technically accessible and made known to users, typically by means such as marketing materials, product documentation, usage messages, or developer support programs. |
Edition |
A Version of the Java Platform. Editions include Java Platform Standard Edition and Java Platform Enterprise Edition. |
Endorsed Standard |
A Java API defined through a standards process other than the Java Community Process. The Endorsed Standard packages are listed later in this chapter. |
Exclude List |
The most current list of tests, distributed by the Maintenance Lead, that are not required to be passed to certify conformance. The Maintenance Lead may add to the Exclude List for that Test Suite as needed at any time, in which case the updated Exclude List supplants any previous Exclude Lists for that Test Suite. |
Java-to-WSDL Output |
Output of a Java-to-WSDL Tool that is required for Web service deployment and invocation. |
Java-to-WSDL Tool |
A software development tool that implements or incorporates a function that generates web service endpoint descriptions in WSDL and XML schema format from Source Code as specified by the JAXWS Specification. |
JSP Page |
A text-based document that uses JavaServer Pages technology. |
JSP Page Implementation Class |
A program constructed by transforming the JSP Page text into a Java language program using the transformation rules described in the Specifications. |
Libraries |
The class libraries, as specified through the Java Community Process (JCP), for the Technology Under Test. The Libraries for Java Platform, Enterprise Edition Version 8 are listed at the end of this chapter. |
Location Resource |
A location of classes or native libraries that are components of the test tools or tests, such that these classes or libraries may be required to exist in a certain location in order to satisfy the requirements of the test suite. For example, classes may be required to exist in directories named in a CLASSPATH variable, or native libraries may be required to exist in directories named in a PATH variable. |
Maintenance Lead |
The Java Community Process member responsible for maintaining the Specification, reference implementation, and TCK for the Technology. Oracle is the Maintenance Lead for Java Platform, Enterprise Edition Version 8. |
Operating Mode |
Any Documented option of a Product that can be changed by a user in order to modify the behavior of the Product. For example, an Operating Mode can be binary (enable/disable optimization), an enumeration (select from a list of protocols), or a range (set the maximum number of active threads). Note that an Operating Mode may be selected by a command line switch, an environment variable, a GUI user interface element, a configuration or control file, etc. |
Product |
A licensee product in which the Technology Under Test is implemented or incorporated, and that is subject to compatibility testing. |
Product Configuration |
A specific setting or instantiation of an Operating Mode. For example, a Product supporting an Operating Mode that permits user selection of an external encryption package may have a Product Configuration that links the Product to that encryption package. |
Rebuildable Tests |
Tests that must be built using an implementation specific mechanism. This mechanism must produce specification-defined artifacts. Rebuilding and running these tests against the Java EE 8 Reference Implementation (RI) verifies that the mechanism generates compatible artifacts. |
Reference Implementation (RI) |
The prototype or "proof of concept" implementation of a Specification. |
Resource |
A Computational Resource, a Location Resource, or a Security Resource. |
Rules |
These definitions and rules in this Compatibility Requirements section of this User’s Guide. |
Runtime |
The Containers specified in the Specifications. |
Security Resource |
A security privilege or policy necessary for the proper execution of the Test Suite. For example, the user executing the Test Suite will need the privilege to access the files and network resources necessary for use of the Product. |
Specifications |
The documents produced through the Java Community Process that define a particular Version of a Technology. The Specifications for the Technology Under Test are referenced later in this chapter. |
Technology |
Specifications and a reference implementation produced through the Java Community Process. |
Technology Under Test |
Specifications and the reference implementation for Java Platform, Enterprise Edition Version 8. |
Test Suite |
The requirements, tests, and testing tools distributed by the Maintenance Lead as applicable to a given Version of the Technology. |
Version |
A release of the Technology, as produced through the Java Community Process. |
WSDL-to-Java Output |
Output of a WSDL-to-Java tool that is required for Web service deployment and invocation. |
WSDL-to-Java Tool |
A software development tool that implements or incorporates a function that generates web service interfaces for clients and endpoints from a WSDL description as specified by the JAXWS Specification. |
The following rules apply for each version of an operating system, software component, and hardware platform Documented as supporting the Product:
EE-WP1 The Product must be able to satisfy all applicable compatibility requirements, including passing all Conformance Tests, in every Product Configuration and in every combination of Product Configurations, except only as specifically exempted by these Rules.
For example, if a Product provides distinct Operating Modes to optimize performance, then that Product must satisfy all applicable compatibility requirements for a Product in each Product Configuration, and combination of Product Configurations, of those Operating Modes.
EE-WP1.1 If an Operating Mode controls a Resource necessary for the basic execution of the Test Suite, testing may always use a Product Configuration of that Operating Mode providing that Resource, even if other Product Configurations do not provide that Resource. Notwithstanding such exceptions, each Product must have at least one set of Product Configurations of such Operating Modes that is able to pass all the Conformance Tests.
For example, a Product with an Operating Mode that controls a security policy (i.e., Security Resource) which has one or more Product Configurations that cause Conformance Tests to fail may be tested using a Product Configuration that allows all Conformance Tests to pass.
EE-WP1.2 A Product Configuration of an Operating Mode that causes the Product to report only version, usage, or diagnostic information is exempted from these compatibility rules.
EE-WP1.3 A Product may contain an Operating Mode that selects the Edition with which it is compatible. The Product must meet the compatibility requirements for the corresponding Edition for all Product Configurations of this Operating Mode. This Operating Mode must affect no smaller unit of execution than an entire Application.
EE-WP1.4 An API Definition Product is exempt from all functional testing requirements defined here, except the signature tests.
EE-WP2 Some Conformance Tests may have properties that may be changed. Properties that can be changed are identified in the configuration interview. Properties that can be changed are identified in the JavaTest Environment (.jte) files in the lib directory of the Test Suite installation. Apart from changing such properties and other allowed modifications described in this User’s Guide (if any), no source or binary code for a Conformance Test may be altered in any way without prior written permission. Any such allowed alterations to the Conformance Tests would be posted to the [Java Licensee Engineering] web site and apply to all licensees.
EE-WP3 The testing tools supplied as part of the Test Suite or as updated by the Maintenance Lead must be used to certify compliance.
EE-WP4 The Exclude List associated with the Test Suite cannot be modified.
EE-WP5 The Maintenance Lead may define exceptions to these Rules. Such exceptions would be made available to and apply to all licensees.
EE-WP6 All hardware and software component additions, deletions, and modifications to a Documented supporting hardware/software platform, that are not part of the Product but required for the Product to satisfy the compatibility requirements, must be Documented and available to users of the Product.
For example, if a patch to a particular version of a supporting operating system is required for the Product to pass the Conformance Tests, that patch must be Documented and available to users of the Product.
EE-WP7 The Product must contain the full set of public and protected classes and interfaces for all the Libraries. Those classes and interfaces must contain exactly the set of public and protected methods, constructors, and fields defined by the Specifications for those Libraries. No subsetting, supersetting, or modifications of the public and protected API of the Libraries are allowed except only as specifically exempted by these Rules.
EE-WP7.1 If a Product includes Technologies in addition to the Technology Under Test, then it must contain the full set of combined public and protected classes and interfaces. The API of the Product must contain the union of the included Technologies. No further modifications to the APIs of the included Technologies are allowed.
EE-WP7.2 A Product may provide a newer version of an Endorsed Standard. Upon request, the Maintenance Lead will make available alternate Conformance Tests as necessary to conform with such newer version of an Endorsed Standard. Such alternate tests will be made available to and apply to all licensees. If a Product provides a newer version of an Endorsed Standard, the version of the Endorsed Standard supported by the Product must be Documented.
EE-WP7.3 The Maintenance Lead may authorize the use of newer Versions of a Technology included in the Technology Under Test. A Product that provides a newer Version of a Technology must meet the Compatibility Requirements for that newer Version, and must Document that it supports the newer Version.
EE-WP8 Except for tests specifically required by this TCK to be rebuilt (if any), the binary Conformance Tests supplied as part of the Test Suite or as updated by the Maintenance Lead must be used to certify compliance.
EE-WP9 The functional programmatic behavior of any binary class or interface must be that defined by the Specifications.
EE-WP9.1 A Product may contain Operating Modes that meet all of these requirements, except Rule T9, provided that:
At least the default Product Configuration of each Operating Mode must meet these requirements, without invoking this rule; testing may always use such a Product Configuration.
The Operating Modes must not violate the Java Platform, Standard Edition Rules.
The Product Configurations of Operating Modes of an application and its components are configured at deployment time, or by administrative action, and can not be changed during the runtime of that application.
Some Product Configurations of such Operating Modes may provide only a subset of the functional programmatic behavior required by the Specifications. The behavior of applications that use more than the provided subset, when run in such Product Configurations, is unspecified.
The functional programmatic behavior of any binary class or interface in the above defined subset must be that defined by the Specifications.
Any Product Configuration that invokes this rule must be clearly Documented as not fully meeting the requirements of the Specifications.
EE-WP10 Each Container must make technically accessible all Java SE Runtime interfaces and functionality, as defined by the Specifications, to programs running in the Container, except only as specifically exempted by these Rules.
EE-WP10.1 Containers may impose security constraints, as defined by the Specifications.
EE-WP11 A web Container must report an error, as defined by the Specifications, when processing a JSP Page that does not conform to the Specifications.
EE-WP12 The presence of a Java language comment or Java language directive in a JSP Page that specifies ”java” as the scripting language, when processed by a web Container, must not cause the functional programmatic behavior of that JSP Page to vary from the functional programmatic behavior of that JSP Page in the absence of that Java language comment or Java language directive.
EE-WP13 The contents of any fixed template data (defined by the Specifications) in a JSP Page, when processed by a web Container, must not affect the functional programmatic behavior of that JSP Page, except as defined by the Specifications.
EE-WP14 The functional programmatic behavior of a JSP Page that specifies ”java” as the scripting language must be equivalent to the functional programmatic behavior of the JSP Page Implementation Class constructed from that JSP Page.
EE-WP15 A Deployment Tool must report an error when processing a Configuration Descriptor that does not conform to the Specifications.
EE-WP16 The presence of an XML comment in a Configuration Descriptor, when processed by a Deployment Tool, must not cause the functional programmatic behavior of the Deployment Tool to vary from the functional programmatic behavior of the Deployment Tool in the absence of that comment.
EE-WP17 A Deployment Tool must report an error when processing an EJB deployment descriptor that includes an EJB QL expression that does not conform to the Specifications.
EE-WP18 The Runtime must report an error when processing a Configuration Descriptor that does not conform to the Specifications.
EE-WP19 The presence of an XML comment in a Configuration Descriptor, when processed by the Runtime, must not cause the functional programmatic behavior of the Runtime to vary from the functional programmatic behavior of the Runtime in the absence of that comment.
EE-WP20 Compatibility testing for the Java EE 8 Web Profile consists of running the tests for the technologies defined in Section 1.2.2, "Java EE 8 Web Profile Technologies Tested With Java EE 8 CTS." If optional technologies defined in the Java EE 8 Web Profile platform are implemented in addition to the required Java EE 8 Web Profile technologies, corresponding tests within this TCK for those additional technologies must also be run.
EE-WP21 Compliance testing for Java EE 8 Web Profile consists of running the Java EE 8 Web Profile tests and the following Technology Compatibility Kits (TCKs):
Contexts and Dependency Injection for Java 2.0 (JSR 365)
Dependency Injection for Java 1.0 (JSR 330)
Bean Validation 2.0(JSR 380)
In addition to the compatibility rules outlined in this CTS User’s Guide, Java EE 8 implementations must also adhere to all of the compatibility rules defined in the User’s Guides of the aforementioned TCKs.
EE-WP22 Source Code in WSDL-to-Java Output when compiled by a Reference Compiler must execute properly when run on a Reference Runtime.
EE-WP23 Source Code in WSDL-to-Java Output must be in source file format defined by the Java Language Specification (JLS).
EE-WP24 Java-to-WSDL Output must fully meet W3C requirements for the Web Services Description Language (WSDL) 1.1.
EE-WP25 A Java-to-WSDL Tool must not produce Java-to-WSDL Output from source code that does not conform to the Java Language Specification (JLS).
Oracle has a well established process for managing challenges to its Java technology Test Suites and plans to continue using a similar process in the future. Oracle, as Java Platform, Enterprise Edition Maintenance Lead, will authorize representatives from the Java Partner Engineering group to be the point of contact for all test challenges. Typically this will be the engineer assigned to a company as part of its Java Platform, Enterprise Edition TCK support.
If a test is determined to be invalid in function or if its basis in the specification is suspect, the test may be challenged by any licensee of the Java Platform, Enterprise Edition TCK. Each test validity issue must be covered by a separate test challenge. Test validity or invalidity will be determined based on its technical correctness such as:
Test has bugs (i.e., program logic errors).
Specification item covered by the test is ambiguous.
Test does not match the specification.
Test assumes unreasonable hardware and/or software requirements.
Test is biased to a particular implementation.
Challenges based upon issues unrelated to technical correctness as defined by the specification will normally be rejected.
Test challenges must be made in writing to Java Partner Engineering and include all relevant information as described in Example 3-1, "Test Challenge Form". The process used to determine the validity or invalidity of a test (or related group of tests) is described in Section 3.3.1, "Java Platform, Enterprise Edition Version 8 TCK Test Appeals Steps"
All tests found to be invalid will either be placed on the Exclude List for that version of the Java Platform, Enterprise Edition TCK or have an alternate test made available.
Tests that are placed on the Exclude List will be placed on the Exclude List within one business day after the determination of test validity. The new Exclude List will be made available to all Java Platform, Enterprise Edition TCK licensees on the Java Platform, Enterprise Edition TCK website.
Oracle, as Maintenance Lead has the option of creating alternative
tests to address any challenge. Alternative tests (and criteria for
their use) will be made available on the Java Platform, Enterprise
Edition TCK website.
|
Note
|
Passing an alternative test is deemed equivalent to passing the original test. |
Java Platform, Enterprise Edition TCK licensee writes a test
challenge to Java Licensee Engineering contesting the validity of one or
a related set of Java Platform, Enterprise Edition tests.
A detailed justification for why each test should be invalidated must be
included with the challenge as described in Example 3-1,
"Test Challenge Form".
Java Licensee Engineering evaluates the challenge.
If the appeal is incomplete or unclear, it is returned to the submitting
licensee for correction. If all is in order, Java Licensee Engineering
will check with the responsible test developers to review the purpose
and validity of the test before writing a response as described in
Example 3-2, "Test Challenge Response Form". Java
Licensee Engineering will attempt to complete the response within 5
business days. If the challenge is similar to a previously rejected test
challenge (i.e., same test and justification), Java Licensee Engineering
will send the previous response to the licensee.
The challenge and any supporting materials from test developers is
sent to the specification engineers for evaluation.
A decision of test validity or invalidity is normally made within 15
working days of receipt of the challenge. All decisions will be
documented with an explanation of why test validity was maintained or
rejected.
The licensee is informed of the decision and proceeds accordingly.
If the test challenge is approved and one or more tests are invalidated,
Oracle places the tests on the Exclude List for that version of the Java
Platform, Enterprise Edition TCK (effectively removing the test(s) from
the Test Suite). All tests placed on the Exclude List will have a bug
report written to document the decision and made available to all
licensees through the bug reporting database. If the test is valid but
difficult to pass due to hardware or operating system limitations,
Oracle may choose to provide an alternate test to use in place of the
original test (all alternate tests are made available to the licensee
community).
If the test challenge is rejected, the licensee may choose to escalate the decision to the Executive Committee (EC), however, it is expected that the licensee would continue to work with Oracle to resolve the issue and only involve the EC as a last resort.
Example 3-1 shows the test challenge information you must provide to Java Licensee Engineering to initiate a challenge, and Example 3-2 shows the test challenge response format.
Example 3-1 Test Challenge Form
Test Challenger Name and Company:
Specification Name(s) and Version(s):
Test Suite Name and Version:
Exclude List Version:
Test Name:
Complaint (argument for why test is invalid):
.jtr file of the failing test:
Console log of the JavaTest harness and device with all debugging flags turned on (if applicable):
.jti or .jte file for the test run:
Startup scripts for the JavaTest harness and agent (if applicable):Example 3-2 Test Challenge Response Form
Test Defender Name and Company:
Test Defender Role in Defense (e.g., test developer, Maintenance Lead, etc.):
Specification Name(s) and Version(s):
Test Suite Name and Version:
Test Name:
Defense (argument for why test is valid):
[Multiple challenges and corresponding responses may be listed here.]
Implications of test invalidity (e.g., other affected tests and test framework code, creation or exposure of ambiguities in spec (due to unspecified requirements), invalidation of the reference implementation, creation of serious holes in test suite):
Alternatives (e.g., are alternate test(s) appropriate?):The Specifications for Java EE 8 Web Profile are found on the JCP web
site at http://jcp.org/en/jsr/detail?id=366.
The following location provides a list of packages that constitute the required class libraries for the full Java EE 8 platform:
http://docs.oracle.com/javaee/8/api/
The following list constitutes the subset of Java EE 8 packages that are required for the Java EE 8 Web Profile:
javax.annotation
javax.annotation.security
javax.annotation.sql
javax.decorator
javax.ejb
javax.ejb.embeddable
javax.ejb.spi
javax.el
javax.enterprise.context
javax.enterprise.context.spi
javax.enterprise.event
javax.enterprise.inject
javax.enterprise.inject.spi
javax.enterprise.util
javax.faces
javax.faces.application
javax.faces.bean
javax.faces.component
javax.faces.component.behavior
javax.faces.component.html
javax.faces.component.visit
javax.faces.context
javax.faces.convert
javax.faces.el
javax.faces.event
javax.faces.flow
javax.faces.flow.builder
javax.faces.lifecycle
javax.faces.model
javax.faces.render
javax.faces.validator
javax.faces.view
javax.faces.view.facelets
javax.faces.webapp
javax.inject
javax.interceptor
javax.json
javax.json.spi
javax.json.stream
javax.persistence
javax.persistence.criteria
javax.persistence.metamodel
javax.persistence.spi
javax.servlet
javax.servlet.annotation
javax.servlet.descriptor
javax.servlet.http
javax.servlet.jsp
javax.servlet.jsp.el
javax.servlet.jsp.jstl.core
javax.servlet.jsp.jstl.fmt
javax.servlet.jsp.jstl.sql
javax.servlet.jsp.jstl.tlv
javax.servlet.jsp.tagext
javax.transaction
javax.transaction.xa
javax.validation
javax.validation.bootstrap
javax.validation.constraints
javax.validation.constraintvalidation
javax.validation.executable
javax.validation.groups
javax.validation.metadata
javax.validation.spi
javax.websocket
javax.websocket.server
javax.ws.rs
javax.ws.rs.client
javax.ws.rs.container
javax.ws.rs.core
javax.ws.rs.ext
javax.json.bind
javax.json.bind.adapter
javax.json.bind.annotation
javax.json.bind.config
javax.json.bind.serializer
javax.json.bind.spi
javax.security.enterprise
javax.security.enterprise.authentication.mechanism.http
javax.security.enterprise.credential
javax.security.enterprise.identitystore
| Previous | Next | Contents |
Copyright © 2018, Oracle and/or its affiliates. All rights reserved.