sun.com docs.sun.com | My Sun Worldwide Sites

|  | Products |  | Downloads |  | Service & Solutions |  | Support |  | Training |  | Research

|  | Previous | Contents |  | Next
Chapter 2 ### Procedure for Java API for RESTful Web Services Certification This chapter describes the compatibility testing process and compatibility requirements for Java API for RESTful Web Services (JSR 311). This chapter contains the following sections: 2.1 Certification Overview 2.2 Compatibility Requirements 2.4 Reference Runtime for Java API for RESTful Web Services 1.1 2.5 Specifications for Java API for RESTful Web Services 1.1 2.6 Libraries for Java API for RESTful Web Services 1.1 ### 2.1 Certification Overview The certification process for Java API for RESTful Web Services 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 2.2 Compatibility Requirements. Certify to Java Licensee Engineering that you have finished testing and that you meet all the compatibility requirements. ### 2.2 Compatibility Requirements The compatibility requirements for Java API for RESTful Web Services consist of meeting the requirements set forth by the rules and associated definitions contained in this section. #### 2.2.1 Definitions These definitions are for use only with these compatibility requirements and are not intended for any other purpose. ###### Table 2-1 Definitions
Term | Definition
--- | ---
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.
Documented | Made technically accessible and made known to users, typically by means such as marketing materials, product documentation, usage messages, or developer support programs.
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.
Libraries | The class libraries, as specified through the Java Community Process (JCP), for the Technology Under Test. The Libraries for Java API for RESTful Web Services 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. Sun is the Maintenance Lead for Java API for RESTful Web Services.
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).
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 5 RI verifies that the mechanism generates compatible artifacts.
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.
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 can be found 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 API for RESTful Web Services.
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.
1. #### 2.2.2 Rules for Java API for RESTful Web Services Products The following rules apply for each version of an operating system, software component, and hardware platform Documented as supporting the Product: 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. 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. 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. A Product may contain an Operating Mode that provides compatibility with previous versions of the Product that would not otherwise meet these compatibility requirements. The previous versions of the Product must have been shipped in a final form to customers before Jan. 1, 2001. At least the default Product Configuration of this Operating Mode must meet these compatibility requirements without invoking this rule; testing may always use such a Product Configuration. This Operating Mode must affect no smaller unit of execution than an entire Application. Any Product Configuration that invokes this rule must be clearly Documented as not meeting the requirements of the Specifications. 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. Some Compatibility Tests may have properties that may be changed. Properties that can be changed are identified in the TCK configuration interview. Apart from changing such properties and other allowed modifications described in this User's Guide (if any), no source or binary code for a Compatibility Test may be altered in any way without prior written permission. Any such allowed alterations to the Compatibility Tests would be posted to the Java Licensee Engineering web site and apply to all licensees. The testing tools supplied as part of the Test Suite or as updated by the Maintenance Lead must be used to certify compliance. The Exclude List associated with the Test Suite cannot be modified. The Maintenance Lead can define exceptions to these Rules. Such exceptions would be made available to and apply to all licensees. 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 Compatibility Tests, that patch must be Documented and available to users of the Product. 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. Except for tests specifically required by this TCK to be rebuilt (if any), the binary Compatibility Tests supplied as part of the Test Suite or as updated by the Maintenance Lead must be used to certify compliance. The functional programmatic behavior of any binary class or interface must be that defined by the Specifications. ### 2.3 Java API for RESTful Web Services 1.1 Test Appeals Process Sun 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. Sun, as Java API for RESTful Web Services 1.1 Maintenance Lead, will authorize representatives from the Java Licensee 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 API for RESTful Web Services 1.1 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 API for RESTful Web Services 1.1 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 Licensee Engineering and include all relevant information as described in step 1 in Java API for RESTful Web Services 1.1 TCK Test Appeals Steps. The process used to determine the validity or invalidity of a test (or related group of tests) is also described in that section. All tests found to be invalid will either be placed on the Exclude List for that version of the Java API for RESTful Web Services 1.1 TCK or have an alternate test made available. Tests that are placed on the Exclude List will be placed on the Exclude List after the determination of test validity. The new Exclude List will be made available to all Java API for RESTful Web Services 1.1 TCK licensees on the Java Licensee Engineering web site. Sun, 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 API for RESTful Web Services 1.1 TCK web site. Note - Passing an alternative test is deemed equivalent to passing the original test. #### Java API for RESTful Web Services 1.1 TCK Test Appeals Steps Java API for RESTful Web Services 1.1 TCK licensee writes a test challenge to Java Licensee Engineering contesting the validity of one or a related set of Java API for RESTful Web Services 1.1 tests. A challenge must be provided to Java Licensee Engineering and include the following information justifying why each test should be invalidated.
       Date:
       Licensee:
       License Contact:
       TCK name and version:
       RI version:
       Java SE version:
       Exclude List version:
       Specification version & section:
       Problem Description:
       Tests Affected:
       Output (inline/attach .jtr file and traces):
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. 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. In necessary, the challenge and any supporting materials from test developers is sent to the assigned Java Licensee engineer or Specification Lead for evaluation. This step only happens if the test engineers cannot come to a resolution. The issue may fall into a grey area and require clarification from the Specification Lead. 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, Sun places the tests on the Exclude List for that version of the Java API for RESTful Web Services 1.1 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, Sun 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 Sun to resolve the issue and only involve the EC as a last resort. ### 2.4 Reference Runtime for Java API for RESTful Web Services 1.1 Designated Reference Implementation for compatibility testing of Java API for RESTful Web Services 1.1 is as follows: Java SE 6 for Solaris x86/SPARC, and Win32 Sun Reference Implementation of JAX-RS Version 1.1. ### 2.5 Specifications for Java API for RESTful Web Services 1.1 The Java API for RESTful Web Services specification is available on the JSR 311 Web site at http://jcp.org/aboutJava/communityprocess/final/jsr311/index.html or on the Java Community Process site. ### 2.6 Libraries for Java API for RESTful Web Services 1.1 The following is a list of the packages comprising the required class libraries JAX-RS 1.1: `javax.ws.rs` `javax.ws.rs.core` `javax.ws.rs.ext` For the latest list of packages, also see: http://jcp.org/en/jsr/detail?id=311 https://jsr311.dev.java.net/
|  | Previous | Contents |  | Next

Company Info Contact Terms of Use Privacy Copyright 1994-2009 Sun Microsystems, Inc.