## Java(TM) API for XML Web Services
JAXWS - 2.2
Specification Assertion Detail

Totals | Total | Active | Deprecated | Removed
# of Assertions | 437 | 403 | 0 | 34
# of Required Assertions | 411 | 380 | 0 | 31
# of Optional Assertions | 26 | 23 | 0 | 3

ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable
JAXWS:SPEC:2001 | 2 |  | Conformance (WSDL1.1 support): Implementations MUST support mapping WSDL 1.1 to Java. | true |  | false | technology | active | true
JAXWS:SPEC:2002 | 2 |  | An application MAY customize the mapping using embedded binding declarations (see section 8.3) or an external binding file (see section 8.4). | true |  | false | technology | active | true
JAXWS:SPEC:2003 | 2 |  | Conformance (Customization required): Implementations MUST support customizing the WSDL 1.1 to Java mapping using the JAX-WS binding language defined in chapter 8. | true |  | false | technology | active | true
JAXWS:SPEC:2004 | 2 |  | Conformance (Annotations on generated classes): The values of all the properties of all the generated annotations MUST be consistent with the information in the source WSDL document and the applicable external binding files. | true |  | false | technology | active | true
JAXWS:SPEC:2075 | 2 |  | Conformance (WSDL Addressing Support): An implementation MUST support the mapping of WS-Addressing 1.0 WSDL Metadata[32] to Java. | true |  | false | technology | removed | true
JAXWS:SPEC:2005 | 2 | 1 | Conformance (Definitions mapping): In the absence of customizations, the Java pakage name is mapped from the value of a wsdl:definitions element's targetNamespace attribute using the algorithm defined by JAXB. | true |  | false | technology | active | true
JAXWS:SPEC:2006 | 2 | 1 | An application MAY customize this mapping using the jaxws:package binding declaration defined in section 8.7.1. | true |  | false | technology | active | true
JAXWS:SPEC:2007 | 2 | 1 | Conformance (WSDL and XML Schema import directives): An implementation MUST support the WS-I Basic Profile 1.1 defined mechanisms (See R2001, R2002, and R2003) for use of WSDL and XML Schema import directives. | true |  | false | technology | active | true
JAXWS:SPEC:2008 | 2 | 1.1 | Conformance (Optional WSDL extensions): An implementation MAY support mapping of additional WSDL extensibility elements and attributes not described in JAX-WS. Note that such support may limit interopability and application portability. | false |  | false | technology | active | false
JAXWS:SPEC:2009 | 2 | 2 | Conformance (SEI naming): In the absence of customizations, the name of an SEI MUST be the value of the name attribute of the corresponding wsdl:portType element mapped according to the rules described in section 2.8. | true |  | false | technology | active | true
JAXWS:SPEC:2010 | 2 | 2 | An application MAY customize this mapping using the jaxws:class binding declaration defined in section 8.7.2. | true |  | false | technology | active | true
JAXWS:SPEC:2011 | 2 | 2 | Conformance (Using the jakarta.jws.WebService annotation): A mapped SEI MUST be annotated with a jakarta.jws.WebService annotation. | true |  | false | technology | active | true
JAXWS:SPEC:2012 | 2 | 2 | Conformance (Extending java.rmi.Remote): A mapped SEI MUST extend java.rmi.Remote. | true |  | false | technology | removed | true
JAXWS:SPEC:2076 | 2 | 2 | Conformance (jakarta.xml.bind.XmlSeeAlso required): An SEI generated from a WSDL that defines types not directly referenced by the Port MUST contain the jakarta.xml.bind.XmlSeeAlso annotation with all of the additional types referenced either directly or indirectly. | true |  | false | technology | active | true
JAXWS:SPEC:2013 | 2 | 3 | Conformance (Method naming): In the absence of customizations, the name of a mapped Java method MUST be the value of the name attribute of the wsdl:operation element mapped according to the rules described in section 2.8. | true |  | false | technology | active | true
JAXWS:SPEC:2014 | 2 | 3 | An application MAY customize thie mapping using the jaxws:method binding declaration defined in section 8.7.3. | true |  | false | technology | active | true
JAXWS:SPEC:2015 | 2 | 3 | Conformance (jakarta.jws.WebMethod required): A mapped Java method MUST be annotated with a jakarta.jws.WebMethod annotation. The annotation MAY be omitted if all its properties would have default values. | true |  | false | technology | active | true
JAXWS:SPEC:2016 | 2 | 3 | Conformance (RemoteException required): A mapped Java method MUST declare java.rmi.RemoteExcpetion in its throws clause. | true |  | false | technology | removed | true
JAXWS:SPEC:2017 | 2 | 3 | Conformance (Transmission primitive support): An implementation MUST support mapping of operations that use the one-way and request-response transmission primitives. | true |  | false | technology | active | true
JAXWS:SPEC:2018 | 2 | 3 | Conformance (using jakarta.jws.OneWay): A Java method mapped from a one-way operation MUST be annotated with a jakarta.jws.OneWay annotation. | true |  | false | technology | active | true
JAXWS:SPEC:2077 | 2 | 3 | Conformance (jakarta.xml.ws.Action): A mapped Java method MUST be annotated with a jakarta.xml.ws.Action annotation if the wsdl:input or wsdl:output elements contain a wsam:Action attribute. | true |  | false | technology | removed | true
JAXWS:SPEC:2078 | 2 | 3 | Conformance (jakarta.xml.ws.Action): If the wsdl:input element contains a wsam:Action, the value of this attribute MUST be set to the jakarta.xml.ws.Action.input element. | true |  | false | technology | removed | true
JAXWS:SPEC:2079 | 2 | 3 | Conformance (jakarta.xml.ws.Action): If the wsdl:output element contains a wsam:Action, the value of this attribute MUST be set to the jakarta.xml.ws.Action.output element. | true |  | false | technology | removed | true
JAXWS:SPEC:2080 | 2 | 3 | Methods generated from wsdl:fault messages that contain a wsam:Action attribute MUST be annotated with jakarta.xml.ws.FaultAction. See section 7 for more information on this annotation. | true |  | false | technology | active | true
JAXWS:SPEC:2081 | 2 | 3 | Conformance (jakarta.xml.ws.FaultAction): A mapped Java method MUST be annotated with a jakarta.xml.ws.FaultAction annotation if the wsdl:fault elements contain a wsam:Action attribute. | true |  | false | technology | removed | true
JAXWS:SPEC:2082 | 2 | 3 | Conformance (jakarta.xml.ws.FaultAction): The jakarta.xml.ws.FaultAction.value is taken directly from the value of the wsam:Action. | true |  | false | technology | removed | true
JAXWS:SPEC:2083 | 2 | 3 | Conformance (jakarta.xml.ws.FaultAction): The jakarta.xml.ws.FaultAction.className MUST be the exception class name associated with this wsdl:fault. | true |  | false | technology | removed | true
JAXWS:SPEC:2019 | 2 | 3.1 | Conformance (Using jakarta.jws.SOAPBinding): An SEI mapped from a port type that is bound using the WSDL SOAP binding MUST be annotated with a jakarta.jws.SOAPBinding annotation describing the choice of style, encoding and parameter style. The annotation MAY be omitted if all its properties would have the default values (i.e. document/literal/wrapped). | true |  | false | technology | active | true
JAXWS:SPEC:2020 | 2 | 3.1 | Conformance (Usingjakarta.jws.WebParam ): Generated Java method parameters MUST be annotated with a jakarta.jws.WebParam annotation. If the style is rpc or if the style is Document and the parameter style is BARE then the partName element of jakarta.jws.WebParam MUST refer to the wsdl:part name of the parameter. | true |  | false | technology | active | true
JAXWS:SPEC:2021 | 2 | 3.1 | Conformance (Usingjakarta.jws.WebResult ): Generated Java methods MUST be annotated with a jakarta.jws.WebResult annotation. If the style is rpc or if the style is Document and the parameter style is BARE then the partName element of jakarta.jws.WebResult MUST refer to the wsdl:part name of the parameter. The annotation MAY be omitted if all its properties would have the default values. | true |  | false | technology | active | true
JAXWS:SPEC:2084 | 2 | 3.1 | Conformance (use of JAXB annotations): An SEI method MUST contain the appropriate JAXB annotations to assure that the proper XML infoset is used when marshalling/unmarshalling the return type. | true |  | false | technology | active | true
JAXWS:SPEC:2085 | 2 | 3.1 | Conformance (use of JAXB annotations): Parameters of an SEI method MUST contain the appropriate JAXB annotations to assure that the proper XML infoset is used when marshalling/unmarshalling the parameters of the method. | true |  | false | technology | active | true
JAXWS:SPEC:2088 | 2 | 3.1 | Conformance (use of JAXB annotations): The set of JAXB annotations that MUST be supported are: jakarta.xml.bind.annotation.XmlAttachementRef, jakarta.xml.bind.annotation.XmlList, jakarta.xml.bind.XmlMimeType and jakarta.xml.bind.annotation.adapters.XmlJavaTypeAdapter. | true |  | false | technology | active | true
JAXWS:SPEC:2022 | 2 | 3.1.1 | Conformance (Non-wrapped parameter naming): In the absence of customization, the name of a mapped Java method parameter MUST be the value of the name attribute of the wsdl:part element mapped according to the rules described in sections 2.8 and 2.8.1. | true |  | false | technology | active | true
JAXWS:SPEC:2023 | 2 | 3.1.1 | An application MAY customize this mapping using the jaxws:parameter binding declaration defined in section 8.7.3. | true |  | false | technology | active | true
JAXWS:SPEC:2024 | 2 | 3.1.2 | A WSDL operation qualifies for wrapper style mapping only if all the criteria as specified are met.(i) The operation s input and output messages (if present) each contain only a single part (ii) The input message part refers to a global element declaration whose localname is equal to the operation name (iii) The output message part refers to a global element declaration (iv) The elements referred to by the input and output message parts (henceforth referred to as wrapper elements) are both complex types defined using the xsd:sequence compositor (v) The wrapper elements only contain child elements, they must not contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they must not be nillable. | true |  | false | technology | active | true
JAXWS:SPEC:2025 | 2 | 3.1.2 | Conformance (Default mapping mode): Operations that do not meet the above criteria MUST be mapped using non-wrapper style. | true |  | false | technology | active | true
JAXWS:SPEC:2026 | 2 | 3.1.2 | Conformance (Disabling wrapper style): Implementations MUST support using the jaxws:enableWrapperStyle binding declaration to enable or disable the wrapper style mapping of operations. | true |  | false | technology | active | true
JAXWS:SPEC:2027 | 2 | 3.1.2 | Conformance (Wrapped parameter naming): In the absence of customization, the name of a mapped Java method parameter MUST be the value of the local name of the wrapper child mapped according to the rules described in sections 2.8 and 2.8.1. | true |  | false | technology | active | true
JAXWS:SPEC:2028 | 2 | 3.1.2 | An application MAY customize this mapping using the jaxws:parameter binding declaration defined in section 8.7.3. | true |  | false | technology | active | true
JAXWS:SPEC:2029 | 2 | 3.1.2 | Conformance (Parameter name clash): If the mapping results in two Java parameters with the same name and one of those parameters is not mapped to the method return type, see section 2.3.2, then this is reported as an error and requires developer intervention to correct, either by disabling wrapper style mapping, modifying the source WSDL or by specifying a customized parameter name mapping. | true |  | false | technology | active | false
JAXWS:SPEC:2072 | 2 | 3.1.2 | Conformance (Using jakarta.xml.ws.RequestWrapper): If wrapper style is used, generated Java methods MUST be annotated with a jakarta.xml.ws.RequestWrapper annotation. The annotation MAY be omitted if all its properties would have the default values. | true |  | false | technology | active | true
JAXWS:SPEC:2073 | 2 | 3.1.2 | Conformance (Using jakarta.xml.ws.ResponseWrapper): If wrapper style is used, generated Java methods MUST be annotated with a jakarta.xml.ws.ResponseWrapper annotation. The annotation MAY be omitted if all its properties would have the default values. | true |  | false | technology | active | true
JAXWS:SPEC:2030 | 2 | 3.2 | Message parts are either listed or unlisted. If the value of a wsdl:part elements name attribute is present in the parameterOrder attribute then the part is listed, otherwise it is unlisted. Parameters that are mapped from message parts are either listed or unlisted. Parameters that are mapped from listed parts are listed; parameters that are mapped from unlisted parts are unlisted. Parameters that are mapped from wrapper children (wrapper style mapping only) are unlisted. Listed parameters appear first in the method signature in the order in which their corresponding parts are listed in the parameterOrder attribute. Unlisted parameters either form the return type or follow the listed parameters The return type is determined as follows: Non-wrapper style mapping Only parameters that are mapped from parts in the abstract output message may form the return type, parts from other messages (see e.g. section 2.6.2.1) do not qualify. If there is a single unlisted out part in the abstract output message then it forms the method return type, otherwise the return type is void. Wrapper style mapping If there is a single out wrapper child then it forms the method return type, if there is an out wrapper child with a local name of return then it forms the method return type, otherwise the return type is void. Unlisted parameters that do not form the return type follow the listed parameters in the following order: 1. Parameters mapped from in and in/out parts appear in the same order the corresponding parts appear in the input message. 2. Parameters mapped from in and in/out wrapper children (wrapper style mapping only) appear in the same order as the corresponding elements appear in the wrapper. 3. Parameters mapped from out parts appear in the same order the corresponding parts appear in the output message. 4. Parameters mapped from out wrapper children (wrapper style mapping only) appear in the same order as the corresponding wrapper children appear in the wrapper. | true |  | false | technology | active | true
JAXWS:SPEC:2031 | 2 | 3.3 | Conformance (Use of Holder ): Implementations MUST map out and in/out method parameters using jakarta.xml.ws.Holder<T> with the exception of a out part that has been mapped to the method's return type. | true |  | false | technology | active | true
JAXWS:SPEC:2032 | 2 | 3.4 | Conformance (Asynchronous mapping required): Implementations MUST support the asynchronous mapping. | true |  | false | technology | active | true
JAXWS:SPEC:2033 | 2 | 3.4 | Conformance (Asynchronous mapping option): An implementation MUST support using the jaxws:enableAsyncMapping binding declaration defined in section 8.7.3 to enable and disable the asynchronous mapping. | true |  | false | technology | active | true
JAXWS:SPEC:2034 | 2 | 3.4.2 | Conformance (Asynchronous method naming): In the absence of customizations, the name of the polling and callback methods MUST be the value of the name attribute of the wsdl:operation suffixed with Async mapped according to the rules described in sections 2.8 and 2.8.1. | true |  | false | technology | active | true
JAXWS:SPEC:2035 | 2 | 3.4.2 | Conformance (Asynchronous parameter naming): The name of the callback handler method parameter MUST be asyncHandler . Parameter name collisions require user intervention to correct, see section 2.8.1. An application MAY customize this mapping using the jaxws:method binding declaration defined in section 8.7.3. | true |  | false | technology | active | true
JAXWS:SPEC:2036 | 2 | 3.4.2 | Conformance (Failed method invocation): If there is any error prior to invocation of the operation, an implementation MUST throw a WebServiceException. | true |  | false | technology | active | false
JAXWS:SPEC:2037 | 2 | 3.4.4 | Conformance (Response bean naming): In the absence of customizations, the name of a response bean MUST be the value of the name attribute of the wsdl:operation suffixed with Response mapped according to the rules described in sections 2.8 and 2.8.1. | true |  | false | technology | active | true
JAXWS:SPEC:2038 | 2 | 3.4.5 | Conformance (Asynchronous fault reporting): A WSDL fault that occurs during execution of an asynchronous method invocation MUST be mapped to a java.util.concurrent.Execution Exception thrown when the client calls Response.get. | true |  | false | technology | active | true
JAXWS:SPEC:2039 | 2 | 3.4.5 | Conformance (Asychronous fault cause): An ExecutionException that is thrown by the get method of Response as a result of a WSDL fault MUST have as its cause the service specific exception mapped from the WSDL fault, if there is one, otherwise the ProtocolException mapped from the WSDL fault (see 6.4). | true |  | false | technology | active | true
JAXWS:SPEC:2040 | 2 | 4 | Conformance (JAXB class mapping): In the absence of user customizations, an implementation MUST use the JAXB class based mapping (generateValueClass="true", generateElementType="false") when mapping WSDL types to Java. | true |  | false | technology | active | true
JAXWS:SPEC:2041 | 2 | 4 | Conformance (JAXB customization use): An implementation MUST support use of JAXB customizations during mapping as detailed in section 8.5. | true |  | false | technology | active | true
JAXWS:SPEC:2042 | 2 | 4 | Conformance (JAXB customization clash): To avoid clashes, if a user customizes the mapping an implementation MUST NOT add the default class based mapping customizations. | true |  | false | technology | active | false
JAXWS:SPEC:2086 | 2 | 4.1 | Conformance (jakarta.xml.ws.wsaddressing.W3CEndpointReference): Any schema element of the type wsa:EndpointReference MUST be mapped to jakarta.xml.ws.wsaddressing.W3CEndpointReference. | true |  | false | technology | active | true
JAXWS:SPEC:2074 | 2 | 5 | Conformance (jakarta.xml.ws.WebFault required): A mapped exception MUST be annotated with a jakarta.xml.ws.WebFault annotation. | true |  | false | technology | active | true
JAXWS:SPEC:2043 | 2 | 5 | Conformance (Exception naming): In the absence of customizations, the name of a mapped exception MUST be the value of the name attribute of the wsdl:message referred to by the wsdl:fault element mapped according to the rules in sections 2.8 and 2.8.1. An application MAY customize this mapping using the jaxws:class binding declaration defined in section 8.7.4. | true |  | false | technology | active | true
JAXWS:SPEC:2044 | 2 | 5 | Conformance (Fault equivalence): An implementation MUST map all equivalent faults within a service to a single Java exception class. | true |  | false | technology | active | true
JAXWS:SPEC:2061 | 2 | 5 | Conformance (Fault equivalence): At runtime an implementation MAY map a serialized fault into any equivalent Java exception. | true |  | false | technology | active | false
JAXWS:SPEC:2045 | 2 | 6 | Conformance (Required WSDL extensions): An implementation MUST support mapping of the WSDL 1.1 specified extension elements for the WSDL SOAP and MIME bindings. | true |  | false | technology | active | true
JAXWS:SPEC:2046 | 2 | 6.1 | Conformance (Unbound message parts): To preserve the protocol independence of mapped operations, an implementation MUST NOT ignore unbound message parts when mapping from WSDL 1.1 to Java. Instead an implementation MUST generate binding code that ignores in and in/out parameters mapped from unbound parts and that presents out parameters mapped from unbound parts as null. | true |  | false | technology | active | false
JAXWS:SPEC:2047 | 2 | 6.2.1 | Conformance (Mapping additional header parts): An implementation MUST support using the jaxws:enableAdditionalSOAPHeaderMapping binding declaration defined in section 8.7.5 as a means to enable mapping of additional parts bound by a soap:header to method parameters. The default is to not map such parts to method parameters. | true |  | false | technology | removed | true
JAXWS:SPEC:2048 | 2 | 6.2.1 | Conformance (Duplicate headers in binding): During mapping, an implementionMUST report an error if the binding of an operation includes two or more soap:header elements that would result in SOAP headers with the same qualified name. | true |  | false | technology | active | false
JAXWS:SPEC:2049 | 2 | 6.2.1 | Conformance (Duplicate headers in Message): During unmarshalling, an implementation MUST generate a runtime error if there is more than one instance of a header whose qualified name is mapped to a method parameter. | true |  | false | technology | active | true
JAXWS:SPEC:2050 | 2 | 6.2.2 | A soap:header element can contain zero or more soap:headerfault elements that describe faults that may arise when processing the header. If the part bound by the soap:header is mapped to a method parameter then each child soap:headerfault is mapped to an additional exception thrown by the mapped method. | true |  | false | technology | removed | true
JAXWS:SPEC:2062 | 2 | 6.2.2 | a soap:headerfault can refer to any single part of a message containing one or more parts. Mapping of soap:headerfault elements follows the mapping for wsdl:fault elements described in section 2.5 with the following differences:1. To avoid name clashes, the mapped Exception is named after the part referred to by the soap:headerfault rather than its parent message.2. The global element that is mapped to a Java bean is the global element referred to by the part named in the soap:headerfault. 3. For the purposes of duplicate removal during mapping, header faults are consider to be equivalent if the values of their message and part attributes are equal. | true |  | false | technology | removed | true
JAXWS:SPEC:2051 | 2 | 6.3.1 | Conformance (Use of MIME type information): An implementation MUST support using the jaxws:enableMIMEContent binding declaration defined in section 8.7.5 to enable or disable the use of the additional metadata in mime:content elements when mapping from WSDL to Java. | true |  | false | technology | active | true
JAXWS:SPEC:2052 | 2 | 6.3.1 | Conformance (MIME type mismatch): An implementation SHOULDthrow a WebServiceException on receipt of a message where the MIME type of a part does not match that described in the WSDL. | false |  | false | technology | active | true
JAXWS:SPEC:2053 | 2 | 6.3.1 | Conformance (MIME part identification): An implementation MUST use the algorithm defined in the WS-I Attachments Profile[29] when generating the MIME Content-ID header field value for a part bound using mime:content. | true |  | false | technology | active | true
JAXWS:SPEC:2054 | 2 | 7 | Conformance (Service superclass required): A generated service class MUST extend the jakarta.xml.ws.Service class. | true |  | false | technology | active | true
JAXWS:SPEC:2069 | 2 | 7 | Conformance (Service class naming): In the absence of customization, the name of a generated service class MUST be the value of the name attribute of the wsdl:service element mapped according to the rules described in sections 2.8 and 2.8.1. | true |  | false | technology | active | true
JAXWS:SPEC:2055 | 2 | 7 | An application MAY customize the name of the generated service class using the jaxws:class binding declaration defined in section 8.7.7. | true |  | false | technology | active | true
JAXWS:SPEC:2063 | 2 | 7 | Conformance (jakarta.xml.ws.WebServiceClient required): A generated service class MUST be annotated with a jakarta.xml.ws.WebServiceClient annotation. | true |  | false | technology | active | true
JAXWS:SPEC:2070 | 2 | 7 | Conformance: A generated service class MUST have a default (i.e. zero-argument) public constructor. This constructor MUST call the protected constructor declared in jakarta.xml.ws.Service, passing as arguments the WSDL location and the service name. The values of the actual arguments for this call MUST be equal (in the java.lang.Object.equals sense) to the values specified in the mandatory WebServiceClient annotation on the generated service class itself. | true |  | false | technology | active | true
JAXWS:SPEC:2071 | 2 | 7 | Conformance: The implementation class MUST have a public constructor that takes two arguments, the wsdl location (a java.net.URL) and the service name (a javax.xml.namespace.QName). This constructor MUST call the protected constructor in jakarta.xml.ws.Service passing as arguments the WSDL location and the service name values with which it was invoked. | true |  | false | technology | active | true
JAXWS:SPEC:2056 | 2 | 7 | Conformance (Failed getPortName Method): A generated getPortName method MUST throw jakarta.xml.ws.WebServiceException on failure. | true |  | false | technology | active | true
JAXWS:SPEC:2064 | 2 | 7 | An application MAY customize the name of the generated methods for a port using the jaxws:method binding declaration defined in section 8.7.8. | true |  | false | technology | active | true
JAXWS:SPEC:2065 | 2 | 7 | Conformance (jakarta.xml.ws.WebEndpoint required): The getPortName methods of generated service interface MUST be annotated with a jakarta.xml.ws.WebEndpoint annotation. | true |  | false | technology | active | true
JAXWS:SPEC:2087 | 2 | 7 | getPortName(WebServiceFeatures... features) One required method that takes a variable-length array of jakarta.xml.ws.WebServiceFeatures and returns a proxy that implements the mapped service endpoint interface. The method generated delegates to the Service.getPort(QName portName, Class>T< SEI, WebServiceFeatures... features) method passing it the port name, the SEI and the features. The value of the port name MUST be equal to the value specified in the mandatory WebEndpoint annotation on the method itself. | true |  | false | technology | active | true
JAXWS:SPEC:2057 | 2 | 8 | Method identifiers When mapping wsdl:operation names to Java method identifiers, the get or set prefix is not added. Instead the first word in the word-list has its first character converted to lower case. | true |  | false | technology | active | true
JAXWS:SPEC:2066 | 2 | 8 | Parameter identifiers When mapping wsdl:part names or wrapper child local names to Java method parameter identifiers, the first word in the word-list has its first character converted to lower case. Clashes with Java language reserved words are reported as errors and require use of appropriate customizations to fix the clash. | true |  | false | technology | active | true
JAXWS:SPEC:2067 | 2 | 8.1 | WSDL name scoping rules may result in name collisions when mapping from WSDL 1.1 to Java. E.g., a port type and a service are both mapped to Java classes but WSDL allows both to be given the same name. This section defines rules for resolving such name collisions. The order of precedence for name collision resolution is as follows (highest to lowest): 1. Service endpoint, interface, 2. Non-exception Java class, 3. Exception class, 4. Service class If a name collision occurs between two identifiers with different precedences, the lower precedence item has its name changed as follows: Non-exception Java class The suffix Type is added to the class name., Exception class The suffix Exception is added to the class name., Service class The suffix Service is added to the class name. | true |  | false | technology | active | true
JAXWS:SPEC:2068 | 2 | 8.1 | If a name collision occurs between a mapped Java method and a method in jakarta.xml.ws.Binding Provider (an interface that proxies are required to implement, see section 4.3), the prefix is added to the mapped method. | true |  | false | technology | active | true
JAXWS:SPEC:2089 | 2 | 3.1 | Message and Part. Add the following: WSDL description may have wsam:Action attribute on wsdl:input, wsdl:output, wsdl:fault elements in a wsdl:operation. This wsam:Action attribute is used to explicitly define the value of the WS-Addressing Action header and this needs to be mapped on to the corresponding Java method. * Conformance (Generating @Action): Generated Java Methods MUST be annotated with @Action and @FaultAction annotations for the corresponding wsdl:input, wsdl:output and wsdl:fault messages that contain wsam:Action attributes * Conformance (Generating @Action input): If a wsdl:input element contains a wsam:Action attribute, the value of the attribute MUST be set to the input element of @Action * Conformance (Generating @Action output): If a wsdl:output element contains a wsam:Action attribute, the value of the attribute MUST be set to the output element of @Action * Conformance (Generating @Action fault): If a wsdl:fault element contains a wsam:Action attribute, the value of the attribute MUST be set to the value element of @FaultAction. The className element of @FaultAction MUST be the exception class name associated with the wsdl:fault | true |  | false | technology | active | true
JAXWS:SPEC:3000 | 3 |  | Conformance Requirement (WSDL 1.1 support): Implementations MUST support mapping Java to WSDL 1.1. | true |  | false | technology | active | true
JAXWS:SPEC:3001 | 3 |  | Conformance Requirement (Standard annotations): An implementation MUST support the use of annotations defined in section 7 to customize the Java to WSDL 1.1 mapping. | true |  | false | technology | active | true
JAXWS:SPEC:3043 | 3 |  | Conformance (WSDL Addressing Support): An implementation MUST support the mapping of Java to WS-Addressing 1.0 WSDL Metadata[32]. | true |  | false | technology | removed | true
JAXWS:SPEC:3002 | 3 | 1 | Conformance Requirement (Java identifier mapping): In the absence of annotations described in this specification, Java identifiers MUST be mapped to XML names using the algorithm defined in appendix B of SOAP 1.2 Part 2[4]. | true |  | false | technology | active | true
JAXWS:SPEC:3003 | 3 | 1.1 | Conformance Requirement (Method name disambiguation): An implementation MUST support the use of the jakarta.jws.WebMethod annotation to disambiguate overloaded Java method names when mapped to WSDL. | true |  | false | technology | active | true
JAXWS:SPEC:3004 | 3 | 2 | Conformance Requirement (Package name mapping): The jakarta.jws.WebService annotation (see section 7.9.1) MAY be used to specify the target namespace to use for a Web service and MUST be used for classes or interfaces in no package. In the absence of a jakarta.jws.WebService annotation the Java package name MUST be mapped to the value of the wsdl:definitions elements targetNamespace attribute using the algorithm: 1. The package name is tokenized using the "." character as a delimiter. 2. The order of the tokens is reversed. 3. The value of the targetNamespace attribute is obtained by concatenating "http://" to the list of tokens separated by "." and "/". | true |  | false | technology | active | true
JAXWS:SPEC:3005 | 3 | 2 | Conformance Requirement (WSDL and XML Schema import directives): Generated WSDL MUST comply with the WS-I Basic Profile 1.0[8] restrictions (See R2001, R2002, and R2003) on usage of WSDL and 16 XML Schema import directives. | true |  | false | technology | active | true
JAXWS:SPEC:3036 | 3 | 3 | Conformance (Class mapping): An implementation MUST support the mapping of jakarta.jws.WebService annotated classes to implicit service endpoint interfaces. | true |  | false | technology | active | true
JAXWS:SPEC:3044 | 3 | 3 | Conformance (jakarta.xml.ws.soap.Addressing): A Java class that is annotated with the jakarta.xml.ws.soap.Addressing annotation with the enabled element set to true, MUST result in the addition of a wsam:Addressing extensibility element to the wsdl:binding element and it MUST NOT have the wsdl:required=true attribute. | true |  | false | technology | removed | true
JAXWS:SPEC:3045 | 3 | 3 | Conformance (jakarta.xml.ws.soap.Addressing): If the required element of the Addressing annotation has a value of true, then the wsam:Addressing extensibility element MUST contain the wsdl:required=true attribute. | true |  | false | technology | removed | true
JAXWS:SPEC:3046 | 3 | 3 | Conformance (jakarta.xml.ws.soap.Addressing): If SEI is also annotated with a BindingType.value is not compatible with this feature an error MUST be given. | true |  | false | technology | removed | false
JAXWS:SPEC:3047 | 3 | 3 | Conformance (jakarta.xml.ws.soap.Addressing): The JAX-WS runtime MUST also use Addressing headers. | true |  | false | technology | removed | true
JAXWS:SPEC:3048 | 3 | 3 | Conformance (jakarta.xml.ws.soap.Addressing): If the enabled element is set to false, then wsam:Addressing element MUST NOT be generated and the JAX-WS runtime MUST NOT use Addressing headers. | true |  | false | technology | removed | true
JAXWS:SPEC:3006 | 3 | 4 | Conformance (Class mapping): An implementation MUST support the mapping of jakarta.jws.WebService annotated classes to implicit service endpoint interfaces. | true |  | false | technology | removed | true
JAXWS:SPEC:3007 | 3 | 4 | Conformance (portType naming): The jakarta.jws.WebService annotation (see section 7.10.1) MAY be used to customize the name and targetNamespace attributes of the wsdl:portType element. If not customized, the value of the name attribute of the wsdl:portType element MUST be the name of the SEI not including the package name and the target namespace is computed as defined above in section 3.2. | true |  | false | technology | active | true
JAXWS:SPEC:3008 | 3 | 4.1 | Conformance Requirement (Inheritance flattening): A mapped wsdl:portType element MUST contain WSDL definitions for all the methods of the corresponding Java SEI including all inherited methods. | true |  | false | technology | active | true
JAXWS:SPEC:3009 | 3 | 4.1 | Conformance Requirement (Inherited interface mapping): An implementation MAY map inherited interfaces to additional wsdl:portType elements within the wsdl:definitions element. | true |  | false | technology | active | false
JAXWS:SPEC:3010 | 3 | 5 | Conformance (Operation naming): In the absence of customizations, the value of the name attribute of the wsdl:operation element MUST be the name of the Java method. The jakarta.jws.WebMethod (see 7.10.2) annotation MAY be used to customize the value of the name attribute of the wsdl:operation element and MUST be used to resolve naming conflicts. If the exclude element of the jakarta.jws.WebMethod is set to true then the Java method MUST NOT be present in the wsdl as a wsdl:operation element. | true |  | false | technology | active | true
JAXWS:SPEC:3011 | 3 | 5 | Methods are either one-way or two-way: one way methods have an input but produce no output, two way methods have an input and produce an output. Section 3.5.1 describes one way operations further. The wsdl:operation element corresponding to each method has one or more child elements as follows: o A wsdl:input element that refers to an associated wsdl:message element to describe the operation input. o (Two-way methods only) an optional wsdl:output element that refers to a wsdl:message to describe the operation output. o (Two-way methods only) zero or more wsdl:fault child elements, one for each exception thrown by the method. The wsdl:fault child elements refer to associated wsdl:message elements to describe each fault. See section 3.7 for further details on exception mapping. | true |  | false | technology | active | true
JAXWS:SPEC:3012 | 3 | 5 | Document style A single wsdl:part child element that refers, via an element attribute, to a global element declaration in the wsdl:types section. | true |  | false | technology | active | true
JAXWS:SPEC:3013 | 3 | 5 | RPC style Zero or more wsdl:part child elements (one per method parameter and one for a non-void return value) that refer, via a type attribute, to named type declarations in the wsdl:types section. | true |  | false | technology | active | true
JAXWS:SPEC:3049 | 3 | 5 | Conformance (jakarta.xml.ws.Action): A Java method annotated with the jakarta.xml.ws.Action.input annotation element MUST result in the addition of a wsam:Action extensibility element to the wsdl:input element with the wsam:Action.value equal to jakarta.xml.ws.Action.input. | true |  | false | technology | removed | true
JAXWS:SPEC:3050 | 3 | 5 | Conformance (jakarta.xml.ws.Action): A Java method annotated with the jakarta.xml.ws.Action.output annotation element MUST result in the addition of a wsam:Action extensibility element on the wsdl:output element with the wsam:Action.value equal to jakarta.xml.ws.Action.output. | true |  | false | technology | removed | true
JAXWS:SPEC:3051 | 3 | 5 | Conformance (jakarta.xml.ws.FaultAction) A Java method annotated with the jakarta.xml.ws.FaultAction annotation element MUST result in the addition of a wsam:Action extensibility element on the wsdl:fault element that corresponds to the Exception specified by jakarta.xml.ws.FaultAction.className with the wsam:Action.value equal to jakarta.xml.ws.FaultAction.value. | true |  | false | technology | removed | true
JAXWS:SPEC:3014 | 3 | 5.1 | Conformance Requirement (One-way mapping): Implementations MUST support using the jakarta.jws.OneWay (see 7.9.3) annotation to specify which methods should be mapped to one-way operations. | true |  | false | technology | active | true
JAXWS:SPEC:3015 | 3 | 5.1 | Conformance Requirement (One-way mapping errors): Implementations MUST prevent mapping to one-way operations of methods that do not meet the necessary criteria. | true |  | false | technology | active | false
JAXWS:SPEC:3052 | 3 | 6 | Conformance (use of JAXB annotations): An implementation MUST honor any JAXB annotation that exists on an SEI method or parameter to assure that the proper XML infoset is used when marshalling/unmarshalling the the return value or parameters of the method. | true |  | false | technology | active | true
JAXWS:SPEC:3054 | 3 | 6 | Conformance (use of JAXB annotations): The set of JAXB annotations that MUST be supported are: jakarta.xml.bind.annotation.XmlAttachementRef, jakarta.xml.bind.annotation.XmlList, jakarta.xml.bind.XmlMimeType and jakarta.xml.bind.annotation.adapters.XmlJavaTypeAdapter. | true |  | false | technology | active | true
JAXWS:SPEC:3016 | 3 | 6.1 | Conformance Requirement (Parameter classification): The jakarta.jws.WebParam annotation (see 7.9.4) MAY be used to specify whether a holder parameter is treated as in/out or out. If not specified, the default MUST be in/out. | true |  | false | technology | active | true
JAXWS:SPEC:3017 | 3 | 6.1 | Conformance (Parameter naming): The jakarta.jws.WebParam annotation (see 7.10.4)MAY be used to specify the name of the wsdl:part or XML Schema element declaration corresponding to a Java parameter. If both the name and partName elements are used in the jakarta.jws.WebParam annotation then the partName MUST be used for the wsdl:part name attribute and the name element from the annotation will be ignored. If not specified, the default is argN, where N is replaced with the zero-based argument index. Thus, for instance, the first argument of a method will have a default parameter name of arg0, the second one arg1and so on. | true |  | false | technology | active | true
JAXWS:SPEC:3018 | 3 | 6.1 | Conformance (Result naming): The jakarta.jws.WebResult annotation (see 7.10.4) MAY be used to specify the name of the wsdl:part or XML Schema element declaration corresponding to the Java method return type. If both the name and partName elements are used in the jakarta.jws.WebResult annotations then the partName MUST be used for the wsdl:part name attribute and the name elment from the annotation will be ignored. In the absence of customizations, the default name is return. | true |  | false | technology | active | true
JAXWS:SPEC:3038 | 3 | 6.1 | Conformance (Header mapping of parameters and results): The jakarta.jws.WebParam annotations - header element MAY be used to map parameters to SOAP headers. Header parameters MUST be included as soap:header elements in the operations input message. The jakarta.jws.WebResult annotations header element MAY be used to map results to SOAP headers. Header results MUST be included as soap:header elements in the operations output message. | true |  | false | technology | active | true
JAXWS:SPEC:3019 | 3 | 6.2 | The jakarta.jws.SOAPBinding annotation MAY be used to specify at the type level which style to use for all methods it contains or on a per method basis if the style is document. | true |  | false | technology | active | true
JAXWS:SPEC:3020 | 3 | 6.2.1 | This style is identified by a jakarta.jws.SOAPBinding annotation with the following properties: a style of DOCUMENT, a use of LITERAL and a parameterStyle of WRAPPED. | true |  | false | technology | active | true
JAXWS:SPEC:3021 | 3 | 6.2.1 | Conformance Requirement (Default wrapper bean names): In the absence of customizations, the wrapper request bean class MUST be named the same as the method and the wrapper response bean class MUST be named the same as the method with a Response suffix. The first letter of each bean name is capitalized to follow Java class naming conventions. | true |  | false | technology | active | true
JAXWS:SPEC:3022 | 3 | 6.2.1 | Conformance Requirement (Default wrapper bean package): In the absence of customizations, the package of the wrapper beans MUST be a generated jaxws subpackage of the SEI package. | true |  | false | technology | active | true
JAXWS:SPEC:3023 | 3 | 6.2.1 | Conformance (Wrapper element names): The jakarta.xml.ws.RequestWrapper and jakarta.xml.ws.ResponseWrapper annotations (see 7.5 and 7.6) MAY be used to specify the localname of the elements generated for the wrapper beans. | true |  | false | technology | removed | true
JAXWS:SPEC:3024 | 3 | 6.2.1 | Conformance (Wrapper element names): The jakarta.xml.ws.RequestWrapper and jakarta.xml.ws.ResponseWrapper annotations (see 7.3 and 7.4) MAY be used to specify the qualified name of the elements generated for the wrapper beans. | true |  | false | technology | active | true
JAXWS:SPEC:3025 | 3 | 6.2.1 | Conformance (Wrapper bean name clash): Generated bean classes must have unique names within a package and MUST NOT clash with other classes in that package. Clashes during generation MUST be reported as an error and require user intervention via name customization to correct. Note that some platforms do not distiguish filenames based on case so comparisons MUST ignore case. | true |  | false | technology | active | false
JAXWS:SPEC:3026 | 3 | 6.2.2 | This style is identified by a jakarta.jws.SOAPBinding annotation with the following properties: a style of DOCUMENT, a use of LITERAL and a parameterStyle of BARE. In order to qualify for use of bare mapping mode a Java method must fulfill all of the following criteria: 1. It must have at most one in or in/out parameter. 2. If it has a return type other than void it must have no in/out or out parameters. 3. If it has a return type of void it must have at most one in/out or out parameter. | true |  | false | technology | active | true
JAXWS:SPEC:3027 | 3 | 6.2.3 | This style is identified by a jakarta.jws.SOAPBinding annotation with the following properties: a style of RPC, a use of LITERAL and a parameterStyle of WRAPPED. The Java types of each in, out and in/out parameter and the return value are mapped to named XML Schema types using the mapping defined by JAXB. For out and in/out parameters the class of the value of the holder is used rather than the holder itself. Each method parameter and the return type is mapped to a message part according to the parameter classification: in The parameter is mapped to a part of the input message. out The parameter or return value is mapped to a part of the output message. in/out The parameter is mapped to a part of the input and output message. The named types are used as the values of the wsdl:part elements type attribute, see figure 3.2. The value of the name attribute of each wsdl:part element is the name of the corresponding method parameter or return for the method return value. | true |  | false | technology | active | true
JAXWS:SPEC:3040 | 3 | 6.2.3 | Conformance (Null Values in rpc/literal): If a null value is passed as an argument to amethod, or returned from amethod, that uses the rpc/literal style, then an implementation MUST throw a WebServiceException. | true |  | false | technology | active | true
JAXWS:SPEC:3028 | 3 | 7 | A service specific Java exception is mapped to a wsdl:fault element, a wsdl:message element with a single child wsdl:part element and an XML Schema global element declaration. The wsdl:fault element appears as a child of the wsdl:operation element that corresponds to the Java method that throws the exception and refers to the wsdl:message element. The wsdl:part element refers to an XML Schema global element declaration that describes the fault. | true |  | false | technology | active | true
JAXWS:SPEC:3029 | 3 | 7 | Conformance Requirement (Exception naming): In the absence of customizations, the name of the global element declaration for a mapped exception MUST be the name of the Java exception. The jakarta.xml.ws.WebFault annotation MAY be used to customize the local name and namespace name of the element. | true |  | false | technology | active | true
JAXWS:SPEC:3030 | 3 | 7 | JAXB defines the mapping from a Java bean to XML Schema element declarations and type definitions and is used to generate the global element declaration that describes the fault. For exceptions that match the pattern described in section 2.5 (i.e. exceptions that have a getFaultInfo method and WebFault annotation), the FaultBean is used as input to JAXB when mapping the exception to XML Schema. For exceptions that do not match the pattern described in section 2.5, JAX-WS maps those exceptions to Java beans and then uses those Java beans as input to the JAXB mapping. The following algorithm is used to map non-matching exception classes to the corresponding Java beans for use with JAXB: In the absence of customizations, the name of the bean is the same as the name of the Exception suffixed with Bean . In the absence of customizations, the package of the bean is a generated jaxws subpackage of the SEI package. E.g. if the SEI package is com.example.stockquote then the package of the bean would be com.example.stockquote.jaxws. For each getter in the exception and its superclasses, a property of the same type and name is added to the bean. The getCause and getLocalizedMessage getters from java.lang.Throwable and the getClass getter from java.lang.Object are excluded from the list of getters to be mapped. The bean is annotated with a JAXB @XmlType annotation whose name property is set to the name of the exception and whose namespace property is set to the namespace name mapped from the exception package name. Additionally, the @XmlType annotation has a propOrder property whose value is an array containing the names of all the properties of the exception class that were mapped in the previous bullet point, sorted lexicographically according to the Unicode value of each of their characters (i.e. using the same algorithm that the int java.lang.String.compareTo(String) method uses). The bean is annotated with a JAXB @XmlRootElement annotation whose name property is set, in the absence of customizations, to the name of the exception. The bean is annotated with a JAXB @XmlType annotation. If the exception class has a @XmlType annotation, then it is used for the fault bean's @XmlType annotation. Otherwise, the fault bean's @XmlType annotation is computed with name property set to the name of the exception and the namespace property set to the target namespace of the corresponding portType. * Conformance(Fault bean's @XmlType): If an exception class has a @XmlType annotation, then it MUST be used for the fault bean's @XmlType annotation. | true |  | false | technology | active | true
JAXWS:SPEC:3031 | 3 | 7 | Conformance Requirement (Fault bean name clash): Generated bean classes must have unique names within a package and MUST NOT clash with other classes in that package. Clashes during generation MUST be reported as an error and require user intervention via name customization to correct. Note that some platforms do not distiguish filenames based on case so comparisons MUST ignore case. | true |  | false | technology | active | false
JAXWS:SPEC:3053 | 3 | 7 | Conformance (java.lang.RuntimeExceptions and java.rmi.RemoteExceptions) java.lang.RuntimeException and java.rmi.RemoteException and their subclasses MUST NOT be treated as service specific exceptions and MUST NOT be mapped to WSDL. | true |  | false | technology | active | true
JAXWS:SPEC:3032 | 3 | 8 | Conformance Requirement (Binding selection): Implementations MUST provide a facility for specifying the binding(s) to use in generated WSDL. | true |  | false | technology | removed | true
JAXWS:SPEC:3041 | 3 | 8 | Conformance (Binding selection): An implementation MUST generate a WSDL binding according to the rules of the binding denoted by the BindingType annotation (see 7.8), if present, otherwise the default is the SOAP 1.1/HTTP binding (see 10). | true |  | false | technology | removed | true
JAXWS:SPEC:3042 | 3 | 9 | In JAX-WS when starting from Java and if generics are used in the document wrapped case, impelementations are required to use type erasure when generating the request /response wrapper beans and exception beans except in the case of Collections. | true |  | false | technology | active | true
JAXWS:SPEC:3033 | 3 | 10 | Conformance Requirement (SOAP binding support): Implementations MUST be able to generate SOAP HTTP bindings when mapping Java to WSDL 1.1. | true |  | false | technology | active | true
JAXWS:SPEC:3034 | 3 | 10.1 | Conformance Requirement (SOAP binding style required): Implementations MUST include a style attribute on a generated soap:binding. | true |  | false | technology | active | true
JAXWS:SPEC:3037 | 3 | 11 | Conformance (Service creation): Implementations MUST be able to map classes annotated with the jakarta.jws.WebService annotation to WSDL wsdl:service elements. | true |  | false | technology | active | true
JAXWS:SPEC:3035 | 3 | 11 | Conformance (Port selection): The portName element of the WebService annotation, if present, MUST be used to derive the port name to use in WSDL. In the absence of a portName element, an implementation MUST use the value of the name element of the WebService annotation, if present, suffixed with Port. Otherwise, an implementation MUST use the simple name of the class annotated with WebService suffixed with Port. | true |  | false | technology | active | true
JAXWS:SPEC:3039 | 3 | 10 | Conformance (Port binding): The WSDL port defined for a service MUST refer to a binding of the type indicated by the BindingType annotation on the service implementation class (see 3.8). | true |  | false | technology | active | true
JAXWS:SPEC:3055 | 3 | 5.2 | wsam:Action Computation Algorithm. All wsdl:operation's child elements wsdl:input, wsdl:output and wsdl:fault must have the wsam:Action attribute in the the generated WSDL. The algorithm to compute wsam:Action from SEI method is as follows: 1. A non-default @Action(input=...) or @WebMethod(action=...) value on a SEI method MUST result into wsdl:input[@wsam:Action] attribute in the corresponding wsdl:operation. Also, @Action(input=...) and @WebMethod(action=...) annotation element values MUST be same, if present. 2. A non-default @Action(output=...) value on a SEI method MUST result into wsdl:output[@wsam:Action] attribute in the corresponding wsdl:operation. 3. A non-default @Action(@FaultAction=...) value on a SEI method MUST result into wsdl:fault[@wsam:Action] attribute in the corresponding wsdl:operation. The wsdl:fault element MUST correspond to the exception specified by className annotated element value. 4. If wsdl:input[@wsam:Action] cannot be mapped from the above steps, then wsam:Action is generated using the metadata defaulting algorithm as if wsdl:input[@name] is not present in WSDL. 5. If wsdl:output[@wsam:Action] cannot be mapped from the above steps, then wsam:Action is generated using the metadata defaulting algorithm as if wsdl:output[@name] is not present in WSDL. 6. If wsdl:fault[@wsam:Action] cannot be mapped from the above steps, then wsam:Action is generated using the metadata defaulting algorithm as if wsdl:fault[@name] is the corresponding exception class name. For example: @Action(input="inAction") public float getPrice(String ticker) throws InvalidTickerException; // the mapped wsdl:operation if targetNamespace="http://example.com" and portType="StockQuoteProvider" <operation name="getPrice"> <input name="foo" message="tns:getPrice" wsam:Action="inAction"/> <output name="bar" message="tns:getPriceResponse" wsam:Action="http://example.com/StockQuoteProvider/getPriceResponse" /> <fault name="FooTickerException" message="tns:InvalidTickerException" wsam:Action="http://example.com/StockQuoteProvider/getPrice/Fault/InvalidTickerException"/> </operation> | true |  | false | technology | active | true
JAXWS:SPEC:3056 | 3 | 6 | Method Parameters and Return Type. JAXB doesn't define any namespace by default to types and elements. In the web services, typically these entities that are created for method parameters and return parameters are qualified. * Conformance (use of JAXB annotations): JAX-WS tools and runtimes MUST override the default empty namespace for JAXB types and elements to SEI's targetNamespace. | true |  | false | technology | active | true
JAXWS:SPEC:3057 | 3 | 6.2.1 | Document Wrapped. Application's programming model doesn't use these bean classes, so the applications need not package these classes. JAX-WS implementations may generate these classes dynamically as specified in this section. * Conformance (Bundling wrapper beans): A JAX-WS implementation SHOULD not require an application to package request and response bean classes. However, when the bean classes are packaged, they MUST be used. The name of wsdl:part for the wrapper must be named as "parameters" and "result" for input and output messages respectively in the generated WSDL. The jakarta.xml.ws.RequestWrapper and jakarta.xml.ws.ResponseWrapper annotations (see 7.3 and 7.4) MAY be used to customize the name of the wsdl:part for the wrapper part. * Conformance (Default Wrapper wsdl:part names): In the absence of customizations, the name of the wsdl:part for the wrapper MUST be named as "parameters" and "result" for input and output messages respectively in the generated WSDL. * Conformance (Customizing Wrapper wsdl:part names): Non-default partName values of the jakarta.xml.ws.RequestWrapper and jakarta.xml.ws.ResponseWrapper annotations, if specified on SEI method, MUST be used as wsdl:part name for input and output messages respectively in the generated WSDL. If a SEI's method parameter or return type is annotated with @XmlElement, that annotation is used for the wrapper bean properties. This can be used to map corresponding XML schema element declaration's attributes like minOccurs, maxOccurs, and nillable etc. It is an error to specify @XmlElement with a parameter or return type that is mapped to header part. If both @XmlElement and @WebParam/@WebResult are present, then it is an error to specify @XmlElement's name, and namespace elements different from @WebParam/@WebResult's name and targetNamespace elements respectively. * Conformance (Wrapper property): If a SEI's method parameter or return type is annotated with @XmlElement, that annotation MUST be used on the wrapper bean property. | true |  | false | technology | active | true
JAXWS:SPEC:3058 | 3 | 7 | Service Specific Exception. * Conformance (Exception naming): In the absence of customizations, the name of the wsdl:message element MUST be the name of the Java exception. The jakarta.xml.ws.WebFault annotation may be used to customize the name of the wsdl:message element and also to resolve any conflicts. * Conformance (Exception naming): If an exception has @WebFault, then messageName MUST be the name of the corresponding wsdl:message element. Application's programming model doesn't use these bean classes, so the applications need not package these classes. JAX-WS implementations may generate these classes dynamically as specified in this section. * Conformance (Bundling wrapper beans): JAX-WS implementations do not require an application to package exception bean classes. However, when the exception bean classes are packaged, they MUST be used. | true |  | false | technology | active | true
JAXWS:SPEC:3059 | 3 | 11 | Service and Ports. If the endpoint enables Addressing, that can be indicated in the generated WSDL as per the Addressing 1.0 - Metadata[35]. * Conformance (Use of Addressing): Endpoint's use of addressing, if any, MUST be indicated in the wsdl:binding or wsdl:port sections of the WSDL 1.1 as per WS-Addressing 1.0 - Metadata[35]. Example 1: Possible Policy assertion for @Addressing in the generated WSDL: ssible Policy assertion for @Addressing in the generated WSDL: <wsam:Addressing wsp:Optional="true"> <wsp:Policy/> </wsam:Addressing> Example 2: Possible Policy assertion for @Addressing(required=true) in the generated WSDL: <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> Example 3: Possible Policy assertion for @Addressing(responses=Responses.NON_ANONYMOUS) in the generated WSDL: <wsam:Addressing wsp:Optional="true"> <wsp:Policy> <wsam:NonAnonymousResponses/> </wsp:Policy> </wsam:Addressing> | true |  | false | technology | active | true
JAXWS:SPEC:4000 | 4 | 1 | Conformance (Service completeness): A Service implementation MUST be capable of creating proxies, Dispatch instances, and new ports. | true |  | false | technology | active | true
JAXWS:SPEC:4001 | 4 | 1.1.1 | Conformance (Service Creation Failure): If a create method fails to create a service object, it MUST throw WebServiceException. The cause of that exception SHOULD be set to an exception that provides more information on the cause of the error (e.g. an IOException). | true |  | false | technology | active | true
JAXWS:SPEC:4002 | 4 | 1.4 | Conformance (Use of Executor): If an executor object is successfully configured for use by a Service via the setExecutor method, then subsequent asynchronous callbacks MUST be delivered using the specified executor. Calls that were outstanding at the time the setExecutor method was called MAY use the previously set executor, if any. | true |  | false | technology | active | true
JAXWS:SPEC:4003 | 4 | 1.4 | Conformance (Default Executor): Lacking an application-specified executor, an implementation MUST use its own executor, a java.util.concurrent.ThreadPoolExecutor or analogous mechanism, to deliver callbacks. An implementation MUST NOT use application-provided threads to deliver callbacks, e.g. by borrowing them when the application invokes a remote operation. | true |  | false | technology | active | true
JAXWS:SPEC:4022 | 4 | 2 | Conformance (Required BindingProvider getEndpointReference): An implementation MUST be able to return an jakarta.xml.ws.EndpointReference for the target endpoint if a SOAP binding is being used. | true |  | false | technology | active | true
JAXWS:SPEC:4023 | 4 | 2 | If the BindingProvider instance has a binding that is either SOAP 1.1/HTTP or SOAP 1.2/HTTP, then a W3CEndpointReference MUST be returned. | true |  | false | technology | active | true
JAXWS:SPEC:4029 | 4 | 2 | The wsam:InterfaceName MAY be present in the wsa:Metdata. | false |  | false | technology | removed | true
JAXWS:SPEC:4024 | 4 | 2 | If the binding is XML/HTTP an java.lang.UnsupportedOperationException MUST be thrown. | true |  | false | technology | active | true
JAXWS:SPEC:4004 | 4 | 2.1 | Conformance (Message context decoupling): Modifications to the request context while previously invoked operations are in-progress MUST NOT affect the contents of the message context for the previously invoked operations. | true |  | false | technology | active | true
JAXWS:SPEC:4005 | 4 | 2.1.1 | Conformance (Required BindingProvider properties): An implementation MUST support all properties shown as mandatory in table 4.1. | true |  | false | technology | active | true
JAXWS:SPEC:4006 | 4 | 2.1.1 | Conformance (OptionalBindingProvider properties): An implementation MAY support the properties shown as optional in table 4.1. | false |  | false | technology | active | true
JAXWS:SPEC:4007 | 4 | 2.1.2 | Conformance (Additional context properties): Implementations MAY define additional implementation specific properties not listed in table 4.1. The java.* and javax.* namespaces are reserved for use by Java specifications. | true |  | false | technology | active | true
JAXWS:SPEC:4008 | 4 | 2.2 | Conformance Requirement (Asynchronous response context): The local response context of a BindingProvider instance MUST NOT be updated on completion of an asynchronous operation, instead the response context MUST be made available via a Response instance. | true |  | false | technology | active | true
JAXWS:SPEC:4009 | 4 | 2.3 | Conformance (Proxy support): An implementation MUST support proxies. | true |  | false | technology | active | true
JAXWS:SPEC:4010 | 4 | 2.3 | Conformance (ImplementingBindingProvider ): An instance of a proxy MUST implement jakarta.xml.ws.BindingProvider. | true |  | false | technology | active | true
JAXWS:SPEC:4011 | 4 | 2.3 | Conformance (Service.getPort failure): If creation of a proxy fails, an implementation MUST throw jakarta.xml.ws.WebServiceException. The cause of that exception SHOULD be set to an exception that provides more information on the cause of the error (e.g. an IOException). | true |  | false | technology | active | true
JAXWS:SPEC:4025 | 4 | 2.3 | Add the following getPort method to the methods of a Service instance. T getPort(Class<T> sei, WebServiceFeatures... features) Returns a proxy for the specified sei, the Service instance is responsible for selecting the port (protocol binding and and endpoint address). The specified features MUST be enabled/disabled and configured as specified. | true |  | false | technology | active | true
JAXWS:SPEC:4026 | 4 | 2.3 | Add the following getPort method to the methods of a Service instance. T getPort(QName port, Class<T> sei, WebServiceFeatures... features) Returns a proxy for the endpoint specified by port. Note that the namespace component of port is the target namespace of the WSDL definition document. The specified features MUST be enabled/disabled and configured as specified. | true |  | false | technology | active | true
JAXWS:SPEC:4027 | 4 | 2.3 | Add the following getPort method to the methods of a Service instance. T getPort(EndpointReference epr Class<T> sei, WebServiceFeatures... features) Returns a proxy for the endpoint specified by epr. The address stored in the epr MUST be used during invocations on the endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:4027.1 | 4 | 2.3 | The endpointReference MUST NOT be used as the value of any addressing header such as wsa:ReplyTo. | true |  | false | technology | active | true
JAXWS:SPEC:4027.2 | 4 | 2.3 | The specified features MUST be enabled/disabled and configured as specified. | true |  | false | technology | active | true
JAXWS:SPEC:4027.3 | 4 | 2.3 | The epr's wsam:ServiceName MUST match the Service instance's ServiceName, otherwise a WebServiceExeption MUST be thrown. | true |  | false | technology | removed | true
JAXWS:SPEC:4027.4 | 4 | 2.3 | The epr's wsam:EndpointName MUST match the PortName for the sei, otherwise a WebServiceException MUST be thrown. | true |  | false | technology | removed | true
JAXWS:SPEC:4027.7 | 4 | 2.3 | Any JAX-WS supported epr metadata MUST match the Service instances ServiceName, otherwise a WebServiceExeption MUST be thrown. | true |  | false | technology | active | true
JAXWS:SPEC:4027.8 | 4 | 2.3 | Any JAX-WS supported epr metadata MUST match the PortName for the sei, otherwise a WebServiceException MUST be thrown. | true |  | false | technology | active | true
JAXWS:SPEC:4027.5 | 4 | 2.3 | If the Service instance has an associated WSDL, its WSDL MUST be used to determine any binding information, any WSDL in the epr will be ignored. | true |  | false | technology | active | true
JAXWS:SPEC:4027.6 | 4 | 2.3 | If the Service instance does not have a WSDL, then any WSDL inlined in the JAX-WS supported metadata of the epr MUST be used to determine binding information. | true |  | false | technology | active | true
JAXWS:SPEC:4027.9 | 4 | 2.3 | If there is not enough metadata in the Service instance or in the epr metadata to determine a port, then a WebServiceException MUST be thrown. | true |  | false | technology | active | true
JAXWS:SPEC:4012 | 4 | 2.4 | Conformance (Remote Exceptions): If an error occurs during a remote operation invocation, an implemention MUST throw a service specific exception if possible. If the error cannot be mapped to a service specific exception, an implementation MUST throw a ProtocolException or one of its subclasses, as appropriate for the binding in use. See section 6.4.1 for more details. | true |  | false | technology | active | true
JAXWS:SPEC:4021 | 4 | 2.4 | Conformance (Exceptions During Handler Processing): Exceptions thrown during handler processing on the client MUST be passed on to the application. If the exception in question is a subclass of WebService Exception then an implementation MUST rethrow it as-is, without any additional wrapping, otherwise it MUST throw a WebServiceExceptionwhose cause is set to the exception that was thrown during handler processing. | true |  | false | technology | active | true
JAXWS:SPEC:4013 | 4 | 2.4 | Conformance (Other Exceptions): For all other errors, i.e. all those that don't occur as part of a remote invocation or handler processing, an implementation MUST throw a WebServiceException whose cause is the original local exception that was thrown, if any. | true |  | false | technology | active | true
JAXWS:SPEC:4014 | 4 | 3 | Conformance (Dispatch support): Implementations MUST support the jakarta.xml.ws.Dispatch interface. | true |  | false | technology | active | true
JAXWS:SPEC:4030 | 4 | 3 | A JAX-WS implementation MUST honor all WebServiceFeatures (section 6.5) for Dispatch based applications. | true |  | false | technology | active | true
JAXWS:SPEC:4015 | 4 | 3.2 | Conformance Requirement (Failed Dispatch.invoke ): When an operation is invoked using an invoke method, an implementation MUST throw a WebServiceException if there is any error in the configuration of the Dispatch instance or a java.rmi.RemoteException if an error occurs during the remote operation invocation. | true |  | false | technology | active | true
JAXWS:SPEC:4016 | 4 | 3.2 | Conformance Requirement (Failed Dispatch.invokeAsync ): When an operation is invoked using an invokeAsync method, an implementation MUST throw a WebServiceException if there is any error in the configuration of the Dispatch instance. Errors that occur during the invocation are reported when the client attempts to retrieve the results of the operation. | true |  | false | technology | active | true
JAXWS:SPEC:4017 | 4 | 3.2 | Conformance Requirement (Failed Dispatch.invokeOneWay ): When an operation is invoked using an invokeOneWay method, an implementation MUST throw a WebServiceException if there is any error in the configuration of the Dispatch instance or if an error is detected1 during the remote operation invocation. | true |  | false | technology | active | true
JAXWS:SPEC:4018 | 4 | 3.3 | Conformance Requirement (Reporting asynchronous errors): An implementation MUST throw a java.util.concurrent.ExecutionException from Response.get if the operation invocation failed. | true |  | false | technology | active | true
JAXWS:SPEC:4019 | 4 | 3.4 | Conformance Requirement (Marshalling failure): If an error occurs when using the supplied JAXBContext to marshall a request or unmarshall a response, an implementation MUST throw a WebServiceException whose cause is set to the original JAXBException. | true |  | false | technology | active | true
JAXWS:SPEC:4020 | 4 | 4 | Conformance (Use of the Catalog): In the process of resolving a URI that points to a WSDL document or any document reachable from it, a JAX-WS implementation MUST perform a URI resolution for it, as prescribed by the XML Catalogs 1.1 specification, using the catalog defined above as its entity catalog. | true |  | false | technology | active | true
JAXWS:SPEC:4028 | 4 | 5 | Section jakarta.xml.ws.EndpointReference getPort(Class<T> serviceEndpointInterface, WebServiceFeature... features) Gets a proxy for the serviceEndpointInterface that can be used to invoke operations on the endpoint referred to by the EndpointReference instance. The specified features MUST be enabled/disabled and configured as specified. | true |  | false | technology | active | true
JAXWS:SPEC:4028.1 | 4 | 5 | The returned proxy MUST use the EndpointReference instance to determine the endpoint address and any reference parameters to be sent on endpoint invocations. | true |  | false | technology | active | true
JAXWS:SPEC:4028.2 | 4 | 5 | The EndpointReference instance MUST NOT be used directly as the value of an WS-Addressing header such as wsa:ReplyTo. | true |  | false | technology | active | true
JAXWS:SPEC:4028.3 | 4 | 5 | For this method to successfully return a proxy, WSDL metadata MUST be available and the EndpointReference instance MUST contain an implementation understood ServiceName in its metadata. | true |  | false | technology | active | true
JAXWS:SPEC:4031 | 4 | 1.1.1 | Dynamic case. create(URL wsdlLocation, QName serviceName, WebServiceFeature ... features) Returns a service object for the specified WSDL document and service name. The created service needs to be configured with the web service features. create(QName serviceName, WebServiceFeature ... features) Returns a service object for a service with the given name. No WSDL document is attached to the service. The created service needs to be configured with the web service features. * Conformance (Service creation using features): The created service object must honor the web service features. If a JAX-WS implementation doesn't understand any passed-in feature, it must throw WebServiceException. | true |  | false | technology | active | true
JAXWS:SPEC:4032 | 4 | 1.1.2 | Static case. When starting from a WSDL document, a concrete service implementation class MUST be generated as defined in section 2.7. The generated implementation class MUST have all the public constructors as shown in the example below. When using the constructors, the default WSDL location and service name are implicitly taken from the WebServiceClient annotation that decorates the generated class. The following code snippet shows the generated constructors: // Generated Service Class @WebServiceClient(name="StockQuoteService", targetNamespace="http://example.com/stocks", wsdlLocation="http://example.com/stocks.wsdl") public class StockQuoteService extends jakarta.xml.ws.Service { public StockQuoteService() { super(new URL("http://example.com/stocks.wsdl"), new QName("http://example.com/stocks", "StockQuoteService")); } public StockQuoteService(WebServiceFeature ... features) { super(new URL("http://example.com/stocks.wsdl"), new QName("http://example.com/stocks", "StockQuoteService"), features); } public StockQuoteService(URL wsdlLocation) { super(wsdlLocation, new QName("http://example.com/stocks", "StockQuoteService")); } public StockQuoteService(URL wsdlLocation, WebServiceFeature ... features) { super(wsdlLocation, new QName("http://example.com/stocks", "StockQuoteService"), features); } public StockQuoteService(URL wsdlLocation, QName serviceName) { super(wsdlLocation, serviceName); } public StockQuoteService(URL wsdlLocation, QName serviceName, WebServiceFeature ... features) { super(wsdlLocation, serviceName, features); } ... } | true |  | false | technology | active | true
JAXWS:SPEC:4033 | 4 | 2 | jakarta.xml.ws.BindingProvider * Conformance (BindingProvider's W3CEndpointReference): The returned W3CEndpointReference MUST contain wsam:ServiceName and wsam:ServiceName[@EndpointName] as per Addressing 1.0 - Metadata[35]. The wsam:InterfaceName MAY be present in the W3CEndpointReference. If there is an associated WSDL, then the WSDL location MUST be referenced using wsdli:wsdlLocation in the W3CEndpointReference's wsa:Metadata. | true |  | false | technology | active | true
JAXWS:SPEC:4033.1 | 4 | 2 | Standard properties. Add the following properties to Table 4.1: Standard BindingProvider properties. Name Type Mandatory Description jakarta.xml.ws.addressing.to EndpointReference Y If WS-Addressing is enabled, this value is used for wsa:To header jakarta.xml.ws.addressing.replyto EndpointReference Y If WS-Addressing is enabled, this value is used for wsa:ReplyTo header jakarta.xml.ws.addressing.faultto EndpointReference Y If WS-Addressing is enabled, this value is used for wsa:FaultTo header | true |  | false | technology | active | true
JAXWS:SPEC:4034 | 4 | 2.3 | Proxies. Proxy instances are not guaranteed to be thread safe. If the instances are accessed by multiple threads, usual synchronization techniques can be used to support multiple threads. The use of WS-Addressing requirements can be indicated in a WSDL as per Addressing 1.0 - Metadata[35]. A proxy created using getPort() calls is configured with the addressing requirements as specified in the associated WSDL or explicitly passing jakarta.xml.ws.soap.AddressingFeature web service feature. * Conformance (Proxy's Addressing use): A proxy MUST be configured with the use of addressing requirements as indicated in the associated WSDL. But if the proxy is created using jakarta.xml.ws.soap.AddressingFeature web service feature, the feature's addressing requirements MUST take precedence over WSDL's addressing requirements. | true |  | false | technology | active | true
JAXWS:SPEC:5000 | 5 | 1 | Conformance (Provider support required): An implementation MUST support Provider<Source> in payload mode with all the predefined bindings. It MUST also support Provider<SOAPMessage> in message mode in conjunction with the predefined SOAP bindings and Provider<jakarta.activation.DataSource@gt; in message mode in conjunction with the predefined HTTP binding. In payload mode, to send a response with no payload, an empty Source payload can be used in payload mode. An empty source can be constructed using zero-argument default constructors of DOMSource, SAXSource, StreamSource. | true |  | false | technology | active | true
JAXWS:SPEC:5001 | 5 | 1 | Conformance Requirement (Provider default constructor): A Provider based service endpoint implementation MUST provide a public default constructor. | true |  | false | technology | active | true
JAXWS:SPEC:5002 | 5 | 1 | Conformance Requirement (Provider implementation): A Provider based service endpoint implementation MUST implement a typed Provider interface. | true |  | false | technology | active | true
JAXWS:SPEC:5003 | 5 | 1 | Conformance (WebServiceProvider annotation): A Provider based service endpoint implementation MUST carry a WebServiceProvider annotation (see 7.7). | true |  | false | technology | active | true
JAXWS:SPEC:5025 | 5 | 1 | A JAX-WS implementation MUST honor all WebServiceFeatures (section 6.5) for Provider based applications. | true |  | false | technology | active | true
JAXWS:SPEC:5004 | 5 | 2.1 | Conformance (Endpoint publish(String address, Object implementor) Method): The effect of invoking the publish method on an Endpoint MUST be the same as first invoking the create method with the binding ID appropriate to the URL scheme used by the address, then invoking the publish(String address) method on the resulting endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:5005 | 5 | 2.1 | Conformance (Default Endpoint Binding): If the URL scheme for the address argument of the Endpoint.publish method is http or https then an implementation MUST use the SOAP 1.1/HTTP binding (see 10) as the binding for the created endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:5006 | 5 | 2.1 | Conformance (Other Bindings): An implementation MAYsupport using the Endpoint.publish method with addresses whose URL scheme is neither http nor https . | false |  | false | technology | active | true
JAXWS:SPEC:5007 | 5 | 2.2 | Conformance (Publishing over HTTP): If the Binding for an Endpoint is a SOAP (see 10) or HTTP (see 11) binding, then an implementation MUST support publishing the Endpoint to a URL whose scheme is either http or https. | true |  | false | technology | active | true
JAXWS:SPEC:5008 | 5 | 2.2 | Conformance (WSDL Publishing): An Endpoint that uses the SOAP 1.1/HTTP binding (see 10) MUST make its contract available as a WSDL 1.1 document at the publishing address suffixed with ?WSDL or ?wsdl . | true |  | false | technology | active | true
JAXWS:SPEC:5009 | 5 | 2.3 | Conformance (CheckingpublishEndpoint Permission): When any of the publish methods defined by the Endpoint class are invoked, an implementation MUST check whether a SecurityManager is installed with the application. If it is, implementations MUST verify that the application has the WebServicePermission identified by the target name publishEndpoint before proceeding. If the permission is not granted, implementations MUST NOT publish the endpoint and they MUST throw a java.lang.SecurityException. | true |  | false | technology | active | true
JAXWS:SPEC:5010 | 5 | 2.4 | Conformance (Required Metadata Types): An implementation MUST support WSDL1.1 and XMLSchema 1.0 documents as metadata. | true |  | false | technology | active | true
JAXWS:SPEC:5013 | 5 | 2.4 | Conformance (Unknown Metadata): An implementation MUST ignore metadata documents whose type it does not recognize. | true |  | false | technology | active | false
JAXWS:SPEC:5014 | 5 | 2.5.1 | If the wsdlLocation annotation element is the empty string, then a JAX-WS implementation must obey the following rules, depending on the binding used by the endpoint: SOAP 1.1/HTTP Binding A JAX-WS implementation MUST generate a WSDL description for the endpoint based on the rules in section 5.2.5.3 below. SOAP 1.2/HTTP Binding A JAX-WS implementation MUST NOT generate a WSDL description for the endpoint. HTTP Binding A JAX-WS implementation MUST NOT generate a WSDL description for the endpoint. Any Implementation-Specific Binding A JAX-WS implementation MAY generate a WSDL description for the endpoint. | true |  | false | technology | active | false
JAXWS:SPEC:5015 | 5 | 2.5.2 | Provider-based endpoints SHOULD have a non-empty wsdlLocation pointing to a valid WSDL description of the endpoint. | false |  | false | technology | active | true
JAXWS:SPEC:5016 | 5 | 2.5.3 | The value of the wsdlLocation annotation element on an endpoint implementation class, if any, MUST be a relative URL. The document it points to MUST be packaged with the application. Moreover, it MUST follow the requirements in section 5.2.5.4 | true |  | false | technology | active | false
JAXWS:SPEC:5017 | 5 | 2.5.3 | At publishing time, a JAX-WS implementation MUST patch the endpoint address in the root description document to match the actual address the endpoint is deployed at. | true |  | false | technology | active | true
JAXWS:SPEC:5018 | 5 | 2.5.3 | A JAX-WS implementation MUST patch the location attributes of all wsdl:import and xsd:import statement in local documents that point to local documents. An implementation MUST NOT patch any other location attributes. | true |  | false | technology | active | true
JAXWS:SPEC:5019 | 5 | 2.5.3 | Implementations MAY support other use cases, but they MUST follow the general rule that any application provided metadata element takes priority over an implementation-generated one, with the exception of the overriding of a port address. | false |  | false | technology | active | true
JAXWS:SPEC:5020 | 5 | 2.5.3 | The exception to using a metadata document as supplied by the application without any modifications is the address of the wsdl:port for the endpoint, which MUST be overridden so as to match the address specified as an argument to the publish method or the one implicit in a server context. | true |  | false | technology | active | true
JAXWS:SPEC:5021 | 5 | 2.5.3 | When publishing the mainWSDL document for an endpoint, an implementation MUST ensure that all references between documents are correct and resolvable. This may require remapping the metadata documents to URLs different from those set as their systemId property. The renaming MUST be consistent, in that the "imports" and "includes" relationships existing between documents when the metadata was supplied to the endpoint MUST be respected at publishing time. Moreover, the same metadata document SHOULD NOT be published at multiple, different URLs. | true |  | false | technology | active | true
JAXWS:SPEC:5022 | 5 | 2.5.3 | When resolving URI references to other documents when processing metadata documents or any of the documents they may transitively reference, a JAX-WS implementation MUST use the catalog facility defined in section 4.4, except when there is a metadata document whose system id matches the URI in question. In other words, metadata documents have priority over catalog-based mappings. | true |  | false | technology | active | true
JAXWS:SPEC:5011 | 5 | 2.7 | Conformance (Use of Executor): If an executor object is successfully set on an Endpoint via the setExecutor method, then an implementation MUST use it to dispatch incoming requests upon publication of the Endpoint by means of the publish(String address) method. If publishing is carried out using the publish(Object serverContext)) method, an implementation MAY use the specified executor or another one specific to the server context being used. | true |  | false | technology | active | true
JAXWS:SPEC:5012 | 5 | 2.7 | Conformance (Default Executor): If an executor has not been set on an Endpoint, an implementation MUST use its own executor, a java.util.concurrent.ThreadPoolExecutor or analogous mechanism, to dispatch incoming requests. | true |  | false | technology | active | true
JAXWS:SPEC:5023 | 5 | 2.8 | Section jakarta.xml.ws.EndpointReference. The following method can be used on a published Endpoint to retrieve an jakarta.xml.ws.EndpointReference for the endpoint. getEndpointReference(List<Element> referenceParameters) Creates and returns and jakarta.xml.ws.EndpointReference for a published Endpoint. If the binding is SOAP 1.1/HTTP or SOAP 1.2/HTTP, then a jakarta.xml.ws.wsaddressing.W3CEndpointReference MUST be returned. | true |  | false | technology | active | true
JAXWS:SPEC:5023.1 | 5 | 2.8 | If the Endpoint instance has an associated WSDL, then a returned W3CEndpointReference MUST in-line the WSDL in the wsa:Metadata and the wsa:Metadata MUST also contain the wsam:ServiceName element with the wsam:EndpointName attribute. | true |  | false | technology | removed | true
JAXWS:SPEC:5023.2 | 5 | 2.8 | A returned W3CEndpointReference MUST also contain the specified referenceParameters. | true |  | false | technology | active | true
JAXWS:SPEC:5023.3 | 5 | 2.8 | An implementation MUST throw a jakarta.xml.ws.WebServiceException if the Endpoint instance has not been published. | true |  | false | technology | active | true
JAXWS:SPEC:5023.4 | 5 | 2.8 | An implementation MUST throw java.lang.UnsupportedOperationException if the Endpoint instance uses the XML/HTTP binding. | true |  | false | technology | active | true
JAXWS:SPEC:5024 | 5 | 2.8 | Section jakarta.xml.ws.EndpointReference The following method can be used on a published Endpoint to retrieve an jakarta.xml.ws.EndpointReference for the endpoint. getEndpointReference(Class<T> clazz, List<Element> referenceParameters) Creates and returns and jakarta.xml.ws.EndpointReference of type clazz for a published Endpoint instance. If clazz is of type jakarta.xml.ws.wsaddressing.W3CEndpointReference then the returned W3CEndpointReference MUST contain the specified referenceParameters. | true |  | false | technology | active | true
JAXWS:SPEC:5024.1 | 5 | 2.8 | A returned W3CEndpointReference MUST also contain the specified referenceParameters. | true |  | false | technology | removed | true
JAXWS:SPEC:5024.2 | 5 | 2.8 | An implementation MUST throw a jakarta.xml.ws.WebServiceException if the Endpoint instance has not been published. | true |  | false | technology | active | true
JAXWS:SPEC:5024.3 | 5 | 2.8 | If the Class clazz is not a subclass of EndpointReference or the Endpoint implementation does not support EndpointReferences of type clazz a jakarta.xml.ws.WebServiceException MUST be thrown. | true |  | false | technology | active | true
JAXWS:SPEC:5024.4 | 5 | 2.8 | An implementation MUST throw java.lang.UnsupportedOperationException if the Endpoint instance uses the XML/HTTP binding. | true |  | false | technology | active | true
JAXWS:SPEC:5026 | 5 | 2.1 | "Endpoints can be created using the following static methods on Endpoint:" create(Object implementor) Creates and returns an Endpoint for the specified implementor. If the implementor specifies a binding using the jakarta.xml.ws.BindingType annotation it MUST be used else a default binding of SOAP 1.1 / HTTP binding MUST be used. create(String bindingID, Object implementor) Creates and returns an Endpoint for the specified binding and implementor. If the bindingID is null and no binding information is specified via the jakarta.xml.ws.BindingType annotation then a default SOAP 1.1 / HTTP binding MUST be used. publish(String address, Object implementor) Creates and publishes an Endpoint for the given implementor. The binding is chosen by default based on the URL scheme of the provided address (which must be a URL). If a suitable binding if found, the endpoint is created then published as if the Endpoint.publish(String address) method had been called. The created Endpoint is then returned as the value of the method. create(Object implementor, WebServiceFeature ... features) Same as the above create() method. The created Endpoint is configured with the web service features. These features override the corresponding features that are specified in WSDL, if present. create(String bindingID, Object implementor, WebServiceFeature ... features) Same as the above create() method. The created Endpoint is configured with the web service features. These features override the corresponding features that are specified in WSDL, if present. publish(String address, Object implementor, WebServiceFeature ... features) Same as the above publish() method. The created Endpoint is configured with the web service features. These features override the corresponding features that are specified in WSDL, if present. | true |  | false | technology | active | true
JAXWS:SPEC:5027 | 5 | 2.8 | Conformance (Endpoint's W3CEndpointReference): The returned W3EndpointReference MUST contain wsam:ServiceName and wsam:ServiceName[@EndpointName] as per Addressing 1.0 - Metadata[35]. The wsam:InterfaceName MAY be present in the W3CEndpointReference. If there is an associated WSDL, then the WSDL location MUST be referenced using wsdli:wsdlLocation in the W3CEndpointReference's wsa:Metadata. | true |  | false | technology | active | true
JAXWS:SPEC:5028 | 5 | 3 | jakarta.xml.ws.WebServiceContext An endpoint implementation can retrieve an jakarta.xml.ws.EndpointReference for the endpoint using getEndpointReference(List<Element> referenceParameters), and getEndpointReference(Class<T> clazz, List<Element> referenceParameters) methods. These methods have the same semantics as the Endpoint.getEndpointReference() methods specified in the section 5.2.8 | true |  | false | technology | active | true
JAXWS:SPEC:5029 | 5 | 4 | Conformance (Building W3CEndpointReference): W3CEndpointReferenceBuilder.build() method MUST construct an EndpointReference as per the Addressing 1.0 - Metadata[35]. | true |  | false | technology | active | true
JAXWS:SPEC:6000 | 6 | 1 | Conformance Requirement (Read-only handler chains): An implementation MAY prevent changes to handler chains configured by some other means (e.g. via a deployment descriptor) by throwing UnsupportedOperationException from the setHandlerChain method of Binding | false |  | false | technology | active | true
JAXWS:SPEC:6001 | 6 | 2 | Conformance (Concrete jakarta.xml.ws.spi.Provider required): An implementation MUST provide a concrete class that extends jakarta.xml.ws.spi.Provider. Such a class MUST have a public constructor which takes no arguments. | true |  | false | technology | active | true
JAXWS:SPEC:6002 | 6 | 2.2 | Conformance (Provider createAndPublishEndpoint Method): The effect of invoking the createAndPublishEndpoint method on a Provider MUST be the same as first invoking the createEndpoint method with the binding ID appropriate to the URL scheme used by the address, then invoking the publish-(String address) method on the resulting endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:6007 | 6 | 2.2 | createEndpoint(String bindingId, Object implementor) Creates and returns an Endpoint for the specified binding and implementor. If the bindingId is null and no binding information is specified via the jakarta.xml.ws.BindingType annotation then a default SOAP1.1/HTTP binding MUST be used. | true |  | false | technology | active | true
JAXWS:SPEC:6018 | 6 | 2.2 | createEndpoint(String bindingID, Object implementor, WebServiceFeature ... features) Same as the above createEndpoint() method. The created Endpoint is configured with the web service features | true |  | false | technology | active | true
JAXWS:SPEC:6019 | 6 | 2.2 | createEndpoint(String bindingId, Class implementorClass, Invoker invoker, WebServiceFeature ... features) Creates an Endpoint for the implementor class and the endpoint invocation is handled by the Invoker. If the bindingId is null and no binding information is specified via the jakarta.xml.ws.BindingType annotation then a default SOAP1.1/HTTP binding MUST be used. The created Endpoint is configured with the web service features. | true |  | false | technology | active | true
JAXWS:SPEC:6020 | 6 | 2.2 | createAndPublishEndpoint(String address, Object implementor, WebServiceFeature ... features) Same as the above createAndPublishEndpoint() method. The created Endpoint is configured with the web service features | true |  | false | technology | active | true
JAXWS:SPEC:6008 | 6 | 2.4 | Creating EndpointReferences The Provider class provides the following method to create EndpointReferences readEndpointReference(javax.xml.transform.Source source) Unmarshalls and returns a jakarta.xml.ws.EndpointReference from the infoset contained in source. | true |  | false | technology | active | true
JAXWS:SPEC:6017 | 6 | 2.4 | Creating EndpointReferences The Provider class provides the following method to create EndpointReferences createW3CEndpointReference(String address, QName serviceName, QName portName, List<Element> metadata, String wsdlDocumentLocation, List<Element> referenceParameters) Creates W3CEndpointReference using the specified parrameters. | true |  | false | technology | active | false
JAXWS:SPEC:6021 | 6 | 2.4 | createW3CEndpointReference(String address, QName interfaceName, QName serviceName, QName portName, List<Element> metadata, String wsdlDocumentLocation, List<Element> referenceParameters, List<Element> elements, Map<QName, String> attributes) Creates W3CEndpointReference using the specified parameters. This method adds support for extension elements, extension attributes, and porttype name. | true |  | false | technology | active | true
JAXWS:SPEC:6009 | 6 | 2.5 | Getting Port Objects: The following method can be used to get a proxy for a Port. getPort(EndpointReference epr, Class<T> sei, WebServiceFeature... features) Gets a proxy for the sei that can be used to invoke operations on the endpoint referred to by the epr. The specified features MUST be enabled/disabled and configured as specified. | true |  | false | technology | active | true
JAXWS:SPEC:6009.1 | 6 | 2.5 | The returned proxy MUST use the epr to determine the endpoint address and any reference parameters that MUST be sent on endpoint invocations. | true |  | false | technology | active | true
JAXWS:SPEC:6009.2 | 6 | 2.5 | The epr MUST NOT be used directly as the value of an WS-Addressing header such as wsa:ReplyTo. | true |  | false | technology | active | true
JAXWS:SPEC:6003 | 6 | 3 | Conformance (Concretejakarta.xml.ws.spi.ServiceDelegate required): An implementation MUST provide a concrete class that extends jakarta.xml.ws.spi.ServiceDelegate. | true |  | false | technology | active | true
JAXWS:SPEC:6004 | 6 | 4.1 | Conformance (Protocol specific fault generation): When throwing an exception as the result of a protocol level fault, an implementation MUST ensure that the exception is an instance of the appropriate ProtocolException subclass. For SOAP the appropriate ProtocolException subclass is SOAPFaultException, for XML/HTTP is is HTTPException. | true |  | false | technology | active | true
JAXWS:SPEC:6005 | 6 | 4.1 | Conformance (Protocol specific fault consumption): When an implementation catches an exception thrown by a service endpoint implementation and the cause of that exception is an instance of the appropriate ProtocolException subclass for the protocol in use, an implementation MUST reflect the information contained in the ProtocolException subclass within the generated protocol level fault. | true |  | false | technology | active | true
JAXWS:SPEC:6006 | 6 | 4.2 | Conformance (One-way operations): When sending a one-way message, implementations MUST throw a WebServiceException if any error is detected when sending the message. | true |  | false | technology | active | true
JAXWS:SPEC:6010 | 6 | 5 | Conformance (jakarta.xml.ws.WebServiceFeatures): Each derived type of jakarta.xml.ws.WebServiceFeature MUST contain a public static final String ID field that uniquely identifies the feature against all features of all implementations. | false |  | false | technology | active | true
JAXWS:SPEC:6011 | 6 | 5 | Conformance (enabled property): Each derived type of jakarta.xml.ws.WebServiceFeature MUST provide a constructor argument and/or method to allow the web service developer to set the value of the enabled property. | true |  | false | technology | active | true
JAXWS:SPEC:6011.1 | 6 | 5 | The public default constructor MUST by default set the enabled property to true. | true |  | false | technology | active | true
JAXWS:SPEC:6011.2 | 6 | 5 | An implementation MUST honor the value of the enabled property of any supported WebServiceFeature. | true |  | false | technology | active | true
JAXWS:SPEC:6012 | 6 | 5.1 | jakarta.xml.ws.soap.AddressingFeature feature MUST be supported with the SOAP 1.1/HTTP or SOAP 1.2/HTTP bindings. | true |  | false | technology | active | true
JAXWS:SPEC:6012.1 | 6 | 5.1 | Enabling this feature on the server will result in the runtime being capable of consuming and responding to WS-Addressing headers. | true |  | false | technology | active | true
JAXWS:SPEC:6012.2 | 6 | 5.1 | Enabling this feature on the client will cause the JAX-WS runtime to include WS-Addressing headers in SOAP messages as specified by WS-Addressing[33]. | true |  | false | technology | active | true
JAXWS:SPEC:6012.3 | 6 | 5.1 | Disabling this feature will prevent a JAX-WS runtime from processing or adding WS-Addressing headers from/to SOAP messages even if the associated WSDL specified otherwise. | true |  | false | technology | active | true
JAXWS:SPEC:6012.4 | 6 | 5.1 | The AddressingFeature's required property can be configured to control whether all incoming messages MUST contain Addressing headers. | true |  | false | technology | active | true
JAXWS:SPEC:6012.5 | 6 | 5.1 | The AddressingFeature's responses property can be configured to control whether the endpoint requires the use of anonymous, non-anonymous and all responses. | true |  | false | technology | active | true
JAXWS:SPEC:6012.6 | 6 | 5.1 | This feature is automatically enabled if the WSDL indicates the use of addressing as per the WS-Addressing 1.0 - Metadata[35]. Developers may choose to prevent this from happening by explicitly disabling the AddressingFeature. | true |  | false | technology | active | true
JAXWS:SPEC:6013 | 6 | 5.1.1 | The abstract EndpointReference class is used by the JAX-WS APIs to reference a particular endpoint in accordance with the W3C Web Services Addressing 1.0 [33]. Each concrete instance of an EndpointReference MUST contain the wsa:Address. | true |  | false | technology | active | true
JAXWS:SPEC:6013.1 | 6 | 5.1.1 | Applications may also use the jakarta.xml.ws.EndpointReference class in method signatures. | false |  | false | technology | active | true
JAXWS:SPEC:6013.2 | 6 | 5.1.1 | JAXB 2.1 will will bind the EndpointReference base class to xs:anyType. | true |  | false | technology | active | true
JAXWS:SPEC:6013.3 | 6 | 5.1.1 | JAX-WS implementations are required to support the W3CEndpointReference class but they may also provide other EndpointReference subclasses that represent different versions of Addressing. | true |  | false | technology | active | true
JAXWS:SPEC:6014 | 6 | 5.1.2 | The jakarta.xml.ws.W3CEndpointReference class is a concrete implementation of the jakarta.xml.ws.EndpointReference class. The W3CEndpointReference class is a concrete implementation of the jakarta.xml.ws.EndpointReference class and is used to reference endpoints that are compliant with the W3C Web Services Addressing 1.0 [24] recommendation. | true |  | false | technology | active | true
JAXWS:SPEC:6014.1 | 6 | 5.1.2 | If an associated WSDL is available, then the W3CEndpointReference SHOULD contain the WSDL in the wsa:MetaData. | false |  | false | technology | removed | true
JAXWS:SPEC:6014.2 | 6 | 5.1.2 | When creating an W3CEndpointReference, it MUST contain the wsam:ServiceName element with the wsam:EndpointName attribute on the wsa:Metadata. | true |  | false | technology | removed | true
JAXWS:SPEC:6014.3 | 6 | 5.1.2 | The wsam:InterfaceName MAY be present. | false |  | false | technology | removed | true
JAXWS:SPEC:6014.4 | 6 | 5.1.2 | Applications may use this class to pass EndpointReferences as method parameters or return types. | true |  | false | technology | active | true
JAXWS:SPEC:6014.5 | 6 | 5.1.2 | JAXB 2.1 will bind the W3CEndpointReference class to the W3C EndpointReference XML Schema in the WSDL. | true |  | false | technology | active | true
JAXWS:SPEC:6015 | 6 | 5.2 | Conformance (jakarta.xml.ws.soap.MTOMFeature): An implementation MUST support the jakarta.xml.ws.soap.MTOMFeature and its threshold property. | true |  | false | technology | active | true
JAXWS:SPEC:6015.1 | 6 | 5.2 | This feature should be used instead of the jakarta.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING, jakarta.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING and the jakarta.xml.ws.soap.SOAPBinding.setMTOMEnabled(). | false |  | false | technology | active | true
JAXWS:SPEC:6015.2 | 6 | 5.2 | This feature MUST be supported with the SOAP 1.1/HTTP or SOAP 1.2/HTTP bindings. | true |  | false | technology | active | true
JAXWS:SPEC:6015.4 | 6 | 5.2 | The MTOMFeature has one property threshold, that can be configured to control which binary data should be XOP encoded. | true |  | false | technology | active | true
JAXWS:SPEC:6015.3 | 6 | 5.2 | Enabling this feature on either the server or client will result the JAX-WS runtime using MTOM and any binary data being XOP encoded. | true |  | false | technology | active | true
JAXWS:SPEC:6015.5 | 6 | 5.2 | The threshold is the size in bytes that binary data MUST be in order to be XOP encoded. | true |  | false | technology | active | true
JAXWS:SPEC:6015.6 | 6 | 5.2 | The threshold MUST not be negative. | true |  | false | technology | active | true
JAXWS:SPEC:6015.7 | 6 | 5.2 | The default value is 0. | true |  | false | technology | active | true
JAXWS:SPEC:6016 | 6 | 5.3 | Conformance (jakarta.xml.ws.RespectBindingFeature): When the jakarta.xml.ws.RespectBindingFeature is enabled, a JAX-WS implementation MUST inspect the wsdl:binding at runtime to determine result and parameter bindings as well as any wsdl:extensions that have the required=true attribute. | true |  | false | technology | active | true
JAXWS:SPEC:6016.1 | 6 | 5.3 | All required wsdl:extensions MUST be supported and honored by a JAX-WS implementation unless a specific wsdl:extension has be explicitly disabled via a WebServiceFeature. | true |  | false | technology | active | true
JAXWS:SPEC:6016.2 | 6 | 5.3 | When this feature is enabled, a JAX-WS implementation must support and honor the addressing policy, if specified, in the WSDL. However, such addressing requirements can be explicitly disabled via AddressingFeature. | true |  | false | technology | active | true
JAXWS:SPEC:6023 | 6 | 6 | Conformance (HTTP SPI in SE platform): A JAX-WS 2.2 implementation in Java SE platform MUST support Endpoint.publish(jakarta.xml.ws.spi.http.HttpContext). | false |  | false | technology | active | false
JAXWS:SPEC:7000 | 7 |  | Conformance (Correctness of annotations): An implementation MUST check at runtime that the annotations pertaining to a method being invoked, either on the client or on the server, as well as any containing program elements (i.e. classes, packages) is in conformance with the specification for that annotation | true |  | false | technology | active | true
JAXWS:SPEC:7001 | 7 |  | Conformance (Handling incorrect annotations): If an incorrect or inconsistent annotation is detected: In a client setting, an implementation MUST NOT invoke the remote operation being invoked, if any. Instead, it MUST throw a WebServiceException, setting its cause to an exception approximating the cause of the error (e.g. an IllegalArgumentException or a ClassNotFoundException). In a server setting, annotation, an implementation MUST NOT dispatch to an endpoint implementation object. Rather, it MUST generate a fault appropriate to the binding in use. | true |  | false | technology | active | true
JAXWS:SPEC:7023 | 7 |  | Conformance (Unsupported WebServiceFeatureAnnotations): If an unrecongnized or unsupported annotation annotated with the WebServiceFeatureAnnotation meta-annotation: | true |  | false | technology | active | false
JAXWS:SPEC:7023.1 | 7 |  | In a client setting, an implementation MUST NOT invoke any remote operations, if any. | true |  | false | technology | active | false
JAXWS:SPEC:7023.2 | 7 |  | In a client setting, Instead, it MUST throw a WebServiceException, setting the cause to an exception approximating the cause of the error. | true |  | false | technology | active | false
JAXWS:SPEC:7023.3 | 7 |  | In a server setting, annotation, an implementation MUST NOT dispatch to an endpoint implementation object. | true |  | false | technology | active | false
JAXWS:SPEC:7023.4 | 7 |  | In a server setting, Rather it MUST generate a fault appropriate to the binding in use. | true |  | false | technology | active | false
JAXWS:SPEC:7002 | 7 | 1 | The ServiceMode annotation is used to specify the mode for a provider class, i.e. whether a provider wants to have access to protocol message payloads (e.g. a SOAP body) or the entire protocol messages (e.g. a SOAP envelope). | true |  | false | technology | active | true
JAXWS:SPEC:7003 | 7 | 2 | The WebFault annotation is used when mapping WSDL faults to Java exceptions, see section 2.5. It is used to capture the name of the fault element used when marshalling the JAXB type generated from the global element referenced by the WSDL fault message. It can also be used to customize the mapping of service specific exceptions to WSDL faults. | true |  | false | technology | active | true
JAXWS:SPEC:7004 | 7 | 3 | The RequestWrapper annotation is applied to the methods of an SEI. It is used to capture the JAXB generated request wrapper bean and the element name and namespace for marshalling / unmarshalling the bean. The default value of localName element is the operationName as defined in WebMethod annotation and the default value for the targetNamespace element is the target namespace of the SEI. When starting from Java, this annotation is used to resolve overloading conflicts in document literal mode. Only the className element is required in this case. | true |  | false | technology | active | true
JAXWS:SPEC:7005 | 7 | 4 | The ResponseWrapper annotation is applied to the methods of an SEI. It is used to capture the JAXB generated response wrapper bean and the element name and namespace for marshalling / unmarshalling the bean. The default value of the localName element is the operationName as defined in the WebMethod appended with Response and the default value of the targetNamespace element is the target namespace of the SEI. When starting from Java, this annotation is used to resolve overloading conflicts in document literal mode. Only the className element is required in this case. | true |  | false | technology | active | true
JAXWS:SPEC:7006 | 7 | 5 | The WebServiceClient annotation is specified on a generated service class (see 2.7). It is used to associate a class with a specific Web service, identify by a URL to a WSDL document and the qualified name of 10 a wsdl:service element. | true |  | false | technology | active | true
JAXWS:SPEC:7007 | 7 | 6 | The WebEndpoint annotation is specified on the getPortName() methods of a generated service class (see 2.7). It is used to associate a get method with a specific wsdl:port, identified by its local name (a NCName). | true |  | false | technology | active | true
JAXWS:SPEC:7008 | 7 | 7 | The WebServiceProvider annotation is specified on classes that implement a strongly typed jakarta.xml.ws.Provider. It is used to declare that a class that satisfies the requirements for a provider (see 5.1) does indeed define a Web service endpoint, much like the WebService annotation does for SEI-based endpoints. | true |  | false | technology | active | true
JAXWS:SPEC:7012 | 7 | 7 | Conformance (WebServiceProvider and WebService): A class annotated with the WebServiceProvider annotation MUST NOT carry a WebService annotation. | true |  | false | technology | active | true
JAXWS:SPEC:7009 | 7 | 8 | The BindingType annotation is applied to an endpoint implementation class. It specifies the binding to use when publishing an endpoint of this type. | true |  | false | technology | active | true
JAXWS:SPEC:7010 | 7 | 9 | The WebServiceRef annotation is used to declare a reference to a Web service. It follows the resource pattern exemplified by the jakarta.annotation.Resource annotation in JSR-250 [31]. The WebServiceRef annotation is required to be honored when running on the Java EE 5 platform, where it is subject to the common resource injection rules described by the platform specification [32]. | true |  | false | technology | active | true
JAXWS:SPEC:7011 | 7 | 10 | Conformance (JSR-181 conformance): A JAX-WS 2.0 implementation MUSTbe conformant to the JAX-WS profile of JSR-181 1.1. As a convenience to the reader, the following sections reproduce the definition of the JSR-181 annotations 8 applicable to JAX-WS. 7.10.1 jakarta.jws.WebService, 7.10.2 jakarta.jws.WebMethod, 7.10.3 jakarta.jws.OneWay, 7.10.4 jakarta.jws.WebParam, 7.10.5 jakarta.jws.WebResult, 7.10.6 jakarta.jws.SOAPBinding, 7.10.7 jakarta.jws.HandlerChain | true |  | false | technology | active | true
JAXWS:SPEC:7013 | 7 | 11 | Conformance (JSR-181 conformance): A JAX-WS 2.0 implementation MUST be conformant to the JAXWS profile of JSR-181 1.1 | true |  | false | technology | active | true
JAXWS:SPEC:7017 | 7 | 12 | The Action annotation is applied to the methods of a SEI. It used to specify the input, output WSAddressing Action values associated with the annotated method. | true |  | false | technology | active | true
JAXWS:SPEC:7017.1 | 7 | 12 | Add the following Table 7.12 Property input Description Action for the wsdl:input operation Default "" | true |  | false | technology | active | true
JAXWS:SPEC:7017.2 | 7 | 12 | Add the following Table 7.12 Property output Description Action for the wsdl:output operation Default "" | true |  | false | technology | active | true
JAXWS:SPEC:7017.3 | 7 | 12 | The Action annotation is applied to the methods of a SEI. | true |  | false | technology | active | true
JAXWS:SPEC:7018 | 7 | 13 | The FaultAction annotation is used within the Action annotation to specify the WS-Addressing Action of a service specific exception. | true |  | false | technology | active | true
JAXWS:SPEC:7018.1 | 7 | 13 | Add the following Table 7.13 Property value Description Action for the wsdl:fault operation Default "" | true |  | false | technology | active | true
JAXWS:SPEC:7018.2 | 7 | 13 | Add the following Table 7.13 Property className Description Name of the exception class Default No defaults, required property | true |  | false | technology | active | true
JAXWS:SPEC:7019 | 7 | 14 | jakarta.xml.ws.spi.WebServiceFeatureAnnotation The WebServiceFeatureAnnotation is a meta-annotation used by a JAX-WS implementation to identify other annotations as WebServiceFeatures. JAX-WS provides the following annotations as WebServiceFeatures: jakarta.xml.ws.soap.Addressing, jakarta.xml.ws.soap.MTOM, and jakarta.xml.ws.RespectBinding. | true |  | false | technology | active | false
JAXWS:SPEC:7019.1 | 7 | 14 | If a JAX-WS implementation encounters an annotation annotated with the WebServiceFeatureAnnotation that it does not support or recognize an ERROR MUST be given. | true |  | false | technology | active | false
JAXWS:SPEC:7019.2 | 7 | 14 | Add the following Table 7.14 Property id Description Unique identifier for the WebServiceFeature represented by the annotated annotation. Default none | true |  | false | technology | active | false
JAXWS:SPEC:7019.3 | 7 | 14 | Add the following Table 7.14 Property bean Description The class name of a derived WebServiceFeature class associated with the annotated annotaion. Default none | true |  | false | technology | active | false
JAXWS:SPEC:7020 | 7 | 14.1 | jakarta.xml.ws.soap.Addressing The Addressing annotation is used to control the use of WS-Addressing[24][33]. It corresponds with the AddressingFeature described in section 6.5.1. | true |  | false | technology | active | true
JAXWS:SPEC:7020.1 | 7 | 14.1 | Add the following Table 7.15 Property enabled Description Specifies if WS-Addressing is enabled or not Default true | true |  | false | technology | active | true
JAXWS:SPEC:7020.2 | 7 | 14.1 | Add the following Table 7.15 Property required Description Specifies Adddressing headers MUST be present on incoming messages. Default false | true |  | false | technology | active | true
JAXWS:SPEC:7020.3 | 7 | 14.1 | an endpoint MUST explicitly specify what WS-Addressing Actions are to be used via the Action and FaultAction annotations. | true |  | false | technology | active | true
JAXWS:SPEC:7020.4 | 7 | 14.1 | The client MUST explicitly enable addresssing via the AddressingFeature, and for each invocation, the client MUST explicitly set the BindingProvider.SOAPACTION URI PROPERTY. | true |  | false | technology | active | true
JAXWS:SPEC:7021 | 7 | 14.2 | jakarta.xml.ws.soap.MTOM The MTOM annotation is used to control the use of MTOM an XOP encoding. It corresponds to the MTOMFeature described in section 6.5.2. | true |  | false | technology | active | true
JAXWS:SPEC:7021.1 | 7 | 14.2 | Add the following Table 7.16 Property enabled Description Specifies if MTOM is enabled or not. Default true | true |  | false | technology | active | true
JAXWS:SPEC:7021.2 | 7 | 14.2 | Add the following Table 7.16 Property threshold Description Specifies the size in bytes that binary data MUST be before being XOP encoded. Default 0 | true |  | false | technology | active | true
JAXWS:SPEC:7022 | 7 | 14.3 | jakarta.xml.ws.RespectBinding The RespectBinding annotation is used to control whether a JAX-WS implementation MUST respect/honor the contents of the wsdl:binding associated with an endpoint. It has a corresponding RespectBindingFeature described in section 6.5.3. | true |  | false | technology | active | true
JAXWS:SPEC:7022.1 | 7 | 14.3 | Add the following Table 7.17 Property enabled Description Specifies whether the wsdl:binding must be respected or not. Default true | true |  | false | technology | active | true
JAXWS:SPEC:8000 | 8 | 1 | Conformance Requirement (Standard binding declarations): The https://jakarta.ee/xml/ns/jaxws namespace is reserved for standard JAX-WS binding declarations. Implementations MUST support all standard JAX-WS binding declarations. Implementation-specific binding declaration extensions MUST NOT use the https://jakarta.ee/xml/ns/jaxws namespace. | true |  | false | technology | active | true
JAXWS:SPEC:8001 | 8 | 1 | Conformance Requirement (Binding language extensibility): Implementations MUST ignore unknown elements and attributes appearing inside a binding declaration whose namespace name is not the one specified in the standard, i.e. https://jakarta.ee/xml/ns/jaxws. | true |  | false | technology | active | true
JAXWS:SPEC:8002 | 8 | 3 | 8.3 Embedded Binding Declarations An embedded binding declaration is specified by using the jaxws:bindings element as a WSDL extension. Embedded binding declarations MAY appear on any of the elements in the WSDL 1.1 namespace that accept extension elements, per the schema for the WSDL 1.1 namespace as amended by the WS-I Basic Profile 1.1[17]. | true |  | false | technology | active | true
JAXWS:SPEC:8003 | 8 | 4 | 8.4 External Binding File The jaxws:bindings element MAY appear as the root element of a XML document. Such a document is called an external binding file. | true |  | false | technology | active | true
JAXWS:SPEC:8004 | 8 | 4 | Conformance (Multiple binding files): Implementations MUST support specifying any number of external JAX-WS and JAXB binding files for processing in conjunction with at least one WSDL document. | true |  | false | technology | active | true
JAXWS:SPEC:8005 | 8 | 5 | 8.5 Using JAXB Binding Declarations It is possible to use JAXB binding declarations in conjunction with JAX-WS. The JAXB 2.0 bindings element, henceforth referred to as jaxb:bindings, MAY appear as an annotation inside a schema document embedded in a WSDL document, i.e. as a descendant of a xs:schema element whose parent is the wsdl:types element. It affects the data binding as specified by JAXB 2.0. Additionally, jaxb:bindings MAY appear inside a JAX-WS external binding file as a child of a jaxws:bindings element whose node attribute points to a xs:schema element inside a WSDL document. When the schema is processed, the outcome MUST be as if the jaxb:bindings element was inlined inside the schema document as an annotation on the schema component. While processing a JAXB binding declaration (i.e. a jaxb:bindings element) for a schema document embedded inside a WSDL document, all XPath expressions that appear inside it MUST be interpreted as if the containing xs:schema element was the root of a standalone schema document. | true |  | false | technology | active | true
JAXWS:SPEC:8006 | 8 | 7.1 | 8.7.1 Definitions The following binding declaration MAY appear in the context of a WSDL document, either as an extension to the wsdl:definitions element or in an external binding file at a place where there is a WSDL document in scope. <jaxws:package name="xs:string">? <jaxws:javadoc>xs:string</jaxws:javadoc>? </jaxws:package> <jaxws:enableWrapperStyle>xs:boolean</jaxws:enableWrapperStyle>? jaxws:enableAsyncMapping>? xs:boolean </jaxws:enableAsyncMapping> <jaxws:enableMIMEContent>? xs:boolean </jaxws:enableMIMEContent> | true |  | false | technology | active | true
JAXWS:SPEC:8007 | 8 | 7.2 | 8.7.2 PortType The following binding declarations MAY appear in the context of a WSDL portType, either as an extension to the wsdl:portType element or with a node attribute pointing at one. <jaxws:class name="xs:string">? <jaxws:javadoc>xs:string</jaxws:javadoc>? </jaxws:class> <jaxws:enableWrapperStyle> xs:boolean </jaxws:enableWrapperStyle>? <jaxws:enableAsyncMapping>xs:boolean</jaxws:enableAsyncMapping> <jaxws:enableMIMEContent>? xs:boolean </jaxws:enableMIMEContent> | true |  | false | technology | active | true
JAXWS:SPEC:8008 | 8 | 7.3 | 8.7.3 PortType Operation The following binding declarations MAY appear in the context of a WSDL portType operation, either as an extension to the wsdl:portType/wsdl:operation element or with a node attribute pointing at one. <jaxws:method name="xs:string">? <jaxws:javadoc>xs:string</jaxws:javadoc>? </jaxws:method> <jaxws:enableWrapperStyle> xs:boolean </jaxws:enableWrapperStyle>? <jaxws:enableAsyncMapping> xs:boolean </jaxws:enableAsyncMapping>? <jaxws:parameter part="xs:string" childElementName="xs:QName"? name="xs:string"/>* | true |  | false | technology | active | true
JAXWS:SPEC:8009 | 8 | 7.4 | 8.7.4 PortType Fault Message The following binding declarations MAY appear in the context of a WSDL portType operations fault message, either as an extension to the wsdl:portType/wsdl:operation/wsdl:fault element or with a node attribute pointing at one. <jaxws:class name="xs:string">? <jaxws:javadoc>xs:string</jaxws:javadoc>? </jaxws:class> | true |  | false | technology | active | true
JAXWS:SPEC:8010 | 8 | 7.5 | 8.7.5 Binding The following binding declarations MAY appear in the context of a WSDL binding, either as an extension to the wsdl:binding element or with a node attribute pointing at one. <jaxws:enableMIMEContent> xs:boolean </jaxws:enableMIMEContent>? | true |  | false | technology | active | true
JAXWS:SPEC:8011 | 8 | 7.6 | 8.7.6 Binding Operation The following binding declarations MAY appear in the context of a WSDL binding operation, either as an extension to the wsdl:binding/wsdl:operation element or with a node attribute pointing at one. <jaxws:enableMIMEContent> xs:boolean </jaxws:enableMIMEContent>? <jaxws:parameter part="xs:string" childElementName="xs:QName"? name="xs:string"/>* <jaxws:exception part="xs:string">* <jaxws:class name="xs:string">? <jaxws:javadoc>xs:string</jaxws:javadoc>? </jaxws:class> </jaxws:exception> | true |  | false | technology | active | true
JAXWS:SPEC:8012 | 8 | 7.7 | 8.7.7 Service The following binding declarations MAY appear in the context of a WSDL service, either as an extension to the wsdl:service element or with a node attribute pointing at one. <jaxws:class name="xs:string">? <jaxws:javadoc>xs:string</jaxws:javadoc>? </jaxws:class> | true |  | false | technology | active | true
JAXWS:SPEC:8013 | 8 | 7.8 | 8.7.8 Port The following binding declarations MAY appear in the context of a WSDL service, either as an extension to the wsdl:port element or with a node attribute pointing at one. <jaxws:method name="xs:string">? <jaxws:javadoc>xs:string</jaxws:javadoc>? </jaxws:method> <jaxws:provider/> | true |  | false | technology | active | true
JAXWS:SPEC:9000 | 9 | 1.1 | Logical handlers are protocol agnostic and are unable to affect protocol specific parts of a message. | true |  | false | technology | active | false
JAXWS:SPEC:9001 | 9 | 1.1 | Protocol handlers are specific to a particular protocol and may access and change protocol specific aspects of a message. | true |  | false | technology | active | true
JAXWS:SPEC:9002 | 9 | 1.2.1 | All binding implementations MUST support logical handlers being deployed in their handler chains. | true |  | false | technology | active | true
JAXWS:SPEC:9003 | 9 | 1.2.1 | Binding implementations MAY support other handler types being deployed in their handler chains. | false |  | true | technology | active | false
JAXWS:SPEC:9004 | 9 | 1.2.1 | An implementation MUST throw WebServiceException when at the time a binding provider is created, the handler chain returned by the configured HandlerResolver contains an incomppatible handler. | true |  | true | technology | active | false
JAXWS:SPEC:9005 | 9 | 1.2.1 | Implementation MUST throw WebServiceException when attempting to confugure an incompatible handler using the Binding.setHandlerChain method. | true |  | true | technology | active | false
JAXWS:SPEC:9006 | 9 | 2.1.1 | Changing the handler resolver configured for a Service instance MUST NOT affect the handlers on previously created proxies, or Dispatch instances. | true |  | false | technology | active | true
JAXWS:SPEC:9007 | 9 | 2.1.2 | The handler chain for a binding is constructed by starting with the handler chain as returned by the HandlerResolver for the service in use and sorting its elements so that all logical handlers precede all protocol handlers. | true |  | false | technology | active | true
JAXWS:SPEC:9008 | 9 | 2.1.3 | When used in conunction with JAX-WS, the name element of the HandlerChain annotation, if present, MUST have the default value (the empty string). | true |  | false | technology | active | true
JAXWS:SPEC:9009 | 9 | 2.1.3 | HandlerChain annotation | true |  | false | technology | active | false
JAXWS:SPEC:9009.1 | 9 | 2.1.3 | An implementation MUST support using the HandlerChain annotation on an endpoint implementation class | true |  | false | technology | active | true
JAXWS:SPEC:9009.2 | 9 | 2.1.3 | An implementation MUST support using the HandlerChain annotation on a provider | true |  | false | technology | active | true
JAXWS:SPEC:9009.3 | 9 | 2.1.3 | An implementation MUST support using the HandlerChain annotation on an endpoint interface | true |  | false | technology | active | true
JAXWS:SPEC:9009.4 | 9 | 2.1.3 | An implementation MUST support using the HandlerChain annotation on a generated service class | true |  | false | technology | active | false
JAXWS:SPEC:9010 | 9 | 2.1.3 | For a generated service class which is annotated with a HandlerChain annotation, the default handler resolver MUST return handler chains consistent with the contents of the handler chain descriptor referenced by the HandlerChain annotation. | true |  | false | technology | active | false
JAXWS:SPEC:9011 | 9 | 2.1.4 | Changing the handler chain on a Binding instance MUST NOT cause any change to the handler chains configured on the Service instance used to create the Binding instance. | true |  | false | technology | active | true
JAXWS:SPEC:9012 | 9 | 3.1 | After injection has been completed, an implementation MUST call the lifecycle method annotated with PostConstruct, if present, prior to invoking any other method on a handler instance. | true |  | false | technology | active | true
JAXWS:SPEC:9013 | 9 | 3.1 | In a managed environment, prior to releasing a handler instance, an implementation MUST call the lifecycle method annotated with PreDestroy method, if present, on any Handler instances which it instantiated. | true |  | false | technology | active | false
JAXWS:SPEC:9014 | 9 | 3.2 | For outbound messages handler processing starts with the first handler in the chain and proceeds in the same order as the handler chain. For inbound messages the order of processing is reversed: processing starts with the last handler in the chain and proceeds in the reverse order of the handler chain. | true |  | false | technology | active | true
JAXWS:SPEC:9015 | 9 | 3.2.1 | handleMessage | true |  | false | technology | active | true
JAXWS:SPEC:9015.1 | 9 | 3.2.1 | Return true This indicates that normal message processing should continue. The runtime invokes handleMessage on the next handler or dispatches the message if there are no further handlers. | true |  | false | technology | active | true
JAXWS:SPEC:9015.2 | 9 | 3.2.1 | Return false This indicates that normal message processing should cease. | true |  | false | technology | active | true
JAXWS:SPEC:9015.2.1 | 9 | 3.2.1 | Response The message direction is reversed, the runtime invokes handleMessage on the next handler or dispatches the message if there are no further handlers. | true |  | false | technology | active | true
JAXWS:SPEC:9015.2.2 | 9 | 3.2.1 | No response Normal message processing stops, close is called on each previously invoked handler in the chain, the message is dispatched. | true |  | false | technology | active | true
JAXWS:SPEC:9015.3 | 9 | 3.2.1 | Throw ProtocolException or a subclass This indicates that normal message processing should cease. | true |  | false | technology | active | true
JAXWS:SPEC:9015.3.1 | 9 | 3.2.1 | Response Normal message processing stops, fault message processing starts. The message direction is reversed, if the message is not already a fault message then it is replaced with a fault message, and the runtime invokes handleFault on the next handler or dispatches the message if there are no further handlers. | true |  | false | technology | active | true
JAXWS:SPEC:9015.3.2 | 9 | 3.2.1 | No response Normal message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched. | true |  | false | technology | active | true
JAXWS:SPEC:9015.4 | 9 | 3.2.1 | Throw any other runtime exception This indicates that normal message processing should cease. | true |  | false | technology | active | true
JAXWS:SPEC:9015.4.1 | 9 | 3.2.1 | Response Normal message processing stops, close is called on each previously invoked handler in the chain, the message direction is reversed, and the exception is dispatched. | true |  | false | technology | active | true
JAXWS:SPEC:9015.4.2 | 9 | 3.2.1 | No response Normal message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched. | true |  | false | technology | active | true
JAXWS:SPEC:9016 | 9 | 3.2.2 | handleFault Called for fault message processing | true |  | false | technology | active | true
JAXWS:SPEC:9016.1 | 9 | 3.2.2 | Return true This indicates that fault message processing should continue. The runtime invokes handle Fault on the next handler or dispatches the fault message if there are no further handlers. | true |  | false | technology | active | true
JAXWS:SPEC:9016.2 | 9 | 3.2.2 | Return false This indicates that fault message processing should cease. Fault message processing stops, close is called on each previously invoked handler in the chain, the fault message is dispatched. | true |  | false | technology | active | true
JAXWS:SPEC:9016.3 | 9 | 3.2.2 | Throw ProtocolException or a subclass This indicates that fault message processing should cease. Fault message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched. | true |  | false | technology | active | true
JAXWS:SPEC:9016.4 | 9 | 3.2.2 | Throw any other runtime exception This indicates that fault message processing should cease. Fault message processing stops, close is called on each previously invoked handler in the chain, the exception is dispatched. | true |  | false | technology | active | true
JAXWS:SPEC:9017 | 9 | 3.2.3 | Invoking close: At the conclusion of an MEP, an implementation MUST call the close method of each handler that was previously invoked during that MEP via either handleMessage or handleFault. | true |  | false | technology | active | true
JAXWS:SPEC:9018 | 9 | 3.2.3 | Conformance (Order of close invocations): Handlers are invoked in the reverse order in which they were first invoked to handle a message according to the rules for normal message processing | true |  | false | technology | active | true
JAXWS:SPEC:9019 | 9 | 3.3 | Handler instances may be pooled by a JAX-WS runtime system. | false |  | true | technology | active | true
JAXWS:SPEC:9020 | 9 | 4 | JAX-WS bindings may define a message context subtype for their particular protocol binding that provides access to protocol specific features. | false |  | true | technology | active | true
JAXWS:SPEC:9021 | 9 | 4.1 | MessageContext is the super interface for all JAX-WS message contexts. It extends Map<String,Object> with additional methods and constants to manage a set of properties that enable handlers in a handler chain to share processing related state. | true |  | false | technology | removed | true
JAXWS:SPEC:9022 | 9 | 4.1 | Properties are scoped as either APPLICATION or HANDLER. All properties are available to all handlers for an instance of an MEP on a particular endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:9023 | 9 | 4.1 | All properties are available to all handlers for an instance of an MEP on a particular endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:9024 | 9 | 4.1 | The defaultscope for a property is HANDLER | true |  | false | technology | active | true
JAXWS:SPEC:9025 | 9 | 4.1 | Properties in a message context MUST be shared across all handler invocations for a particular instance of an MEP on any particular endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:9026 | 9 | 4.1.1 | jakarta.xml.ws.handler.message.outbound Specifies the message direction: true for outbound messages, false for inbound messages. | true |  | false | technology | active | true
JAXWS:SPEC:9027 | 9 | 4.1.1 | jakarta.xml.ws.binding.attachments A map of attachments to a message. The key is a unique identifier for the attachment. The value is a DataHandler for the attachment data.Bindings describe how to carry attachments with messages. | true |  | false | technology | active | true
JAXWS:SPEC:9028 | 9 | 4.1.1 | jakarta.xml.ws.wsdl.description A resolvable URI that may be used to obtain access to the WSDL for the endpoint. | false |  | false | technology | active | true
JAXWS:SPEC:9029 | 9 | 4.1.1 | jakarta.xml.ws.wsdl.service The name of the service being invoked in the WSDL. | false |  | false | technology | active | true
JAXWS:SPEC:9030 | 9 | 4.1.1 | jakarta.xml.ws.wsdl.port The name of the port over which the current message was received in the WSDL. | false |  | false | technology | active | true
JAXWS:SPEC:9031 | 9 | 4.1.1 | jakarta.xml.ws.wsdl.interface The name of the interface (WSDL 2.0) or port type (WSDL 1.1) to which the current message belongs. | false |  | false | technology | active | true
JAXWS:SPEC:9032 | 9 | 4.1.1 | jakarta.xml.ws.wsdl.operation The name of the WSDL operation to which the current message belongs. For WSDL 2.0 this is the operation component designator. For WSDL 1.1 the namespace is the target namespace of the WSDL definitions element. | false |  | false | technology | active | true
JAXWS:SPEC:9033 | 9 | 4.1.1 | jakarta.xml.ws.http.request.headers A map of the HTTP headers for the request message. The key is the header name. The value is a list of values for that header. | true |  | false | technology | active | true
JAXWS:SPEC:9034 | 9 | 4.1.1 | jakarta.xml.ws.http.request.method The HTTP method for the request message. | true |  | false | technology | active | true
JAXWS:SPEC:9035 | 9 | 4.1.1 | jakarta.xml.ws.http.response.headers A map of the HTTP headers for the response message. The key is the header name. The value is a list of values for that header. | true |  | false | technology | active | true
JAXWS:SPEC:9036 | 9 | 4.1.1 | jakarta.xml.ws.http.response.code The HTTP response status code. | true |  | false | technology | active | true
JAXWS:SPEC:9037 | 9 | 4.1.1 | jakarta.xml.ws.servlet.context The ServletContext object belonging to the web application that contains the endpoint. | true |  | false | technology | active | true
JAXWS:SPEC:9038 | 9 | 4.1.1 | jakarta.xml.ws.servlet.request The HttpServletRequest object associated with the request currently being served. | true |  | false | technology | active | true
JAXWS:SPEC:9039 | 9 | 4.1.1 | jakarta.xml.ws.servlet.response The HttpServletResponse object associated with the request currently being served. | true |  | false | technology | active | true
JAXWS:SPEC:9040 | 9 | 4.1.1 | jakarta.xml.ws.servlet.session The HttpSession associated with the request currently being served. | true |  | false | technology | active | true
JAXWS:SPEC:9042 | 9 | 4.1.1 | Handler Framework, Standard Message Context Properties | true |  | false | technology | active | true
JAXWS:SPEC:9042.1 | 9 | 4.1.1 | Add the jakarta.xml.ws.reference.parameters property to Table 9.2. Name jakarta.xml.ws.reference.parameters Type List<Element> Mandatory Y Description A list of WS Addressing headers marked with the wsa:IsReferenceParameter=true attribute. | true |  | false | technology | active | true
JAXWS:SPEC:9041 | 9 | 4.3 | Handlers may manipulate the values and scope of properties within the message context as desired. | true |  | false | technology | active | true
JAXWS:SPEC:10000 | 10 | 1.1.1 | Conformance Requirement (SOAP required roles): An implementation of the SOAP binding MUST act in the following roles: next and ultimate receiver. | true |  | false | technology | active | false
JAXWS:SPEC:10001 | 10 | 1.1.1 | Conformance Requirement (SOAP required roles): An implementation of the SOAP binding MUST NOT act in the none role. | true |  | false | technology | active | false
JAXWS:SPEC:10002 | 10 | 1.1.1 | Conformance Requirement (Default role visibility): An implementation MUST include the required next and ultimate receiver roles in the Set returned from SOAPBinding.getRoles. | true |  | false | technology | active | true
JAXWS:SPEC:10003 | 10 | 1.1.1 | Conformance Requirement (Default role persistence): An implementation MUST add the required next and ultimate receiver roles to the roles configured with SOAPBinding.setRoles. | true |  | false | technology | active | true
JAXWS:SPEC:10004 | 10 | 1.1.1 | Conformance Requirement (None role error): An implementation MUST throw WebServiceException if a client attempts to configure the binding to play the none role via SOAPBinding.setRoles. | true |  | false | technology | active | true
JAXWS:SPEC:10005 | 10 | 1.1.2 | Conformance (Incompatible handlers): An implementation MUST throw WebServiceException when, at the time a binding provider is created, the handler chain returned by the configured HandlerResolver contains an incompatible handler. | true |  | false | technology | active | false
JAXWS:SPEC:10006 | 10 | 1.1.2 | Conformance Requirement (Incompatible handlers): Implementations MUST throw a WebServiceException when attempting to configure an incompatible handler using Binding.setHandlerChain. | true |  | false | technology | active | true
JAXWS:SPEC:10007 | 10 | 1.1.2 | Conformance Requirement (Logical handler access): An implementation MUST allow access to the contents of the SOAP body via a logical message context. | true |  | false | technology | active | true
JAXWS:SPEC:10008 | 10 | 2.1 | SOAP mustUnderstand Processing: The SOAP protocol binding performs the following additional processing on inbound SOAP messages prior to the start of normal handler invocation processing (see section 9.3.2). Refer to the SOAP specification[2, 3, 6 4] for a normative description of the SOAP processing model. This section is not intended to supercede any requirement stated within the SOAP specification, but rather to outline how the configuration information described above is combined to satisfy the SOAP requirements: 1. Obtain the set of SOAP roles for the current binding instance. This is returned by SOAPBinding.getRoles. 2. Obtain the set of Handlers deployed on the current binding instance. This is obtained via Binding.getHandlerChain. 3. Identify the set of header qualified names (QNames) that the binding instance understands. This is the set of all header QNames: (a) that are mapped to method parameters in the service endpoint interface, and (b) obtained from Handler.getHeaders() for each Handler in the set obtained in step 2. 4. Identify the set of must understand headers in the inbound message that are targeted at this node. This is the set of all headers with a mustUnderstand attribute whose value is 1 or true and an actor or role attribute whose value is in the set obtained in step 1. 5. For each header in the set obtained in step 4, the header is understood if its QName is in the set identified in step 3. 6. If every header in the set obtained in step 4 is understood, then the node understands how to process the message. Otherwise the node does not understand how to process the message. 7. If the node does not understand how to process the message, then neither handlers nor the endpoint are invoked and instead the binding generates a SOAPmust understand exception. Subsequent actions depend on whether the message exchange pattern (MEP) in use requires a response to the message currently being processed or not: Response The message direction is reversed and the binding dispatches the SOAP must understand exception (see section 10.2.2). No response The binding dispatches the SOAP must understand exception (see section 10.2.2). | true |  | false | technology | active | true
JAXWS:SPEC:10009 | 10 | 2.2.1 | Handler Exceptions: A binding is responsible for catching runtime exceptions thrown by handlers and following the processing model described in section 9.3.2. A binding is responsible for converting the exception to a fault message subject to further handler processing if the following criteria are met: 1. A handler throws a ProtocolException from handleMessage, handleRequest or handleResponse2. The MEP in use includes a response to the message being processed 3. The current message is not already a fault message (the handler might have undertaken the work prior to throwing the exception). If the above criteria are met then the exception is converted to a SOAP fault message as follows: If the exception is an instance of SOAPFaultException then the fields of the exception are serialized 11 to a new SOAP fault message, see section 10.2.2.3. The current message is replaced by the new SOAP 12 fault message. If the exception is of any other type then a new SOAP fault message is created to reflect a server class of error for SOAP 1.1[2] or a receiver class of error for SOAP 1.2[3]. Handler processing is resumed as described in section 9.3.2. If the criteria for converting the exception to a fault message subject to further handler processing are not met then the exception is handled as follows depending on the current message direction: Outbound A new SOAP fault message is created to reflect a server class of error for SOAP 1.1[2] or a receiver class of error for SOAP 1.2[3] and the message is dispatched. Inbound The exception is passed to the binding provider. | true |  | false | technology | active | true
JAXWS:SPEC:10010 | 10 | 2.2.3 | Mapping Exceptions to SOAP Faults: When mapping an exception to a SOAP fault, the fields of the fault message are populated according to the following rules of precedence: faultcode (Subcode in SOAP 1.2, Code set to env:Receiver) 1. SOAPFaultException.getFaultCode()1 2. env:Server (Subcode omitted for SOAP 1.2).faultstring (Reason/Text 1. SOAPFaultException.getFaultString()1 2. Exception.getMessage() 3. Exception.toString()faultactor (Role in SOAP 1.2) 1. SOAPFaultException.getFaultActor()1 2. Emptydetail (Detail in SOAP 1.2) 1. Serialized service specific exception (see WrapperException.getFaultInfo() in section 2.5) 2. SOAPFaultException.getDetail()1 | true |  | false | technology | active | true
JAXWS:SPEC:10011 | 10 | 4.1 | Conformance Requirement (SOAP 1.1 HTTP Binding Support): An implementation MUST support the HTTP binding of SOAP 1.1[2] and SOAP With Attachments[30] as clarified by the WS-I Basic Profile[17], WS-I Simple SOAP Binding Profile[28] and WS-I Attachment Profile[29]. | true |  | false | technology | active | true
JAXWS:SPEC:10012 | 10 | 4.1 | Conformance Requirement (SOAP 1.2 HTTP Binding Support): An implementation MUST support the HTTP binding of SOAP 1.2[4]. | true |  | false | technology | active | true
JAXWS:SPEC:10013 | 10 | 4.1.1 | Conformance Requirement (SOAP MTOM Support): An implementation MUST support SOAP MTOM[26]. | true |  | false | technology | active | true
JAXWS:SPEC:10022 | 10 | 4.1.1 | Conformance (Semantics of MTOM enabled): When MTOM is enabled, a receiver MUST accept both non-optimized and optimized messages, and a sender MAY send an optimized message, non-optimized messages being also acceptable. | true |  | false | technology | active | true
JAXWS:SPEC:10014 | 10 | 4.1.1 | Conformance (MTOM support): Predefined SOAPBinding instances MUST support enabling/disabling MTOM support using the setMTOMenabled method. | true |  | false | technology | active | true
JAXWS:SPEC:10023 | 10 | 4.1.1 | Conformance (SOAP bindings with MTOM disabled): The bindings corresponding to the following IDs: jakarta.xml.ws.soap.SOAPBinding.SOAP11HTTP BINDING and jakarta.xml.ws.soap.SOAPBinding.SOAP12HTTP BINDING MUST have MTOM disabled by default. | true |  | false | technology | active | true
JAXWS:SPEC:10024 | 10 | 4.1.1 | Conformance (SOAP bindings with MTOM enabled): The bindings corresponding to the following IDs: jakarta.xml.ws.soap.SOAPBinding.SOAP11HTTP MTOM BINDING and jakarta.xml.ws.soap.SOAPBinding.SOAP12HTTP MTOM BINDING MUST have MTOM enabled by default. | true |  | false | technology | active | true
JAXWS:SPEC:10015 | 10 | 4.1.1 | Conformance (MTOM on Other SOAP Bindings): Other bindings that extend SOAPBinding MAY NOT support changing the value of the MTOMEnabled property. In this case, if an application attempts to change its value, an implementation MUST throw a WebServiceException. | true |  | false | technology | active | true
JAXWS:SPEC:10016 | 10 | 4.1.2 | Conformance Requirement (One-way operations): When invoking one-way operations, an implementation of the SOAP/HTTP binding MUST block until the HTTP response is received or an error occurs. | true |  | false | technology | active | true
JAXWS:SPEC:10025 | 10 | 4.1.2 | Addressing section: If the jakarta.xml.ws.soap.AddressingFeature is enabled, implementations are required to follow WS-Addressing[32,33,34] protocols. | true |  | false | technology | active | true
JAXWS:SPEC:10026 | 10 | 4.1.2 | Conformance (SOAP Addressing Support): An implementation MUST support WS-Addressing 1.0 SOAP Binding[34]. | true |  | false | technology | active | true
JAXWS:SPEC:10017 | 10 | 4.1.3 | Conformance Requirement (HTTP basic authentication support): An implementation of the SOAP/HTTP binding MUST support HTTP basic authentication. | true |  | false | technology | active | true
JAXWS:SPEC:10018 | 10 | 4.1.3 | Conformance Requirement (Authentication properties): A client side implementation MUST support use of the the standard properties jakarta.xml.ws.security.auth.usernameand jakarta.xml.ws.security.auth.password to configure HTTP basic authentication. | true |  | false | technology | active | true
JAXWS:SPEC:10019 | 10 | 4.1.4 | Conformance Requirement (URL rewriting support): An implementation MUST support use of HTTP URL rewriting for state management. | true |  | false | technology | active | true
JAXWS:SPEC:10020 | 10 | 4.1.4 | Conformance Requirement (Cookie support): An implementation SHOULD support use of HTTP cookies for state management. | false |  | false | technology | active | true
JAXWS:SPEC:10021 | 10 | 4.1.4 | Conformance Requirement (SSL session support): An implementation MAY support use of SSL session based state management. | false |  | false | technology | active | true
JAXWS:SPEC:10027 | 10 | 4.1.5 | If addressing is enabled, implementations are required to follow WS-Addressing[24][33][35] protocols. * Conformance (SOAP Addressing Support): An implementation MUST supportWS-Addressing 1.0 SOAP Binding[33]. * Conformance (wsa:Action value): wsa:Action value MUST be got from @Action annotation elements in SEI, if present. But if a client sets a BindingProvider.SOAPACTION_URI_PROPERTY then that MUST be used for wsa:Action header. If a receiver receives messages with the WS-Addressing headers that are non-conformant as per WS-Addressing 1.0- SOAP Binding[33], then appropriate addressing pre-defined faults must be generated. A JAX-WS application may send wsa:replyTo or wsa:FaultTo addressing header to receive non-anonymous responses at a different address other than the transport back channel. When the application receives a response at a different address, there is no standard way to communicate the response with the JAX-WS client runtime. Hence, there are no requirements on a JAX-WS client runtime to bind non-anonymous responses. A JAX-WS client runtime may start an endpoint to receive a non-anonymous response and may use the response to bind to the java parameters and return type. However, it is not required to do so. | true |  | false | technology | active | true
JAXWS:SPEC:11000 | 11 | 1 | Conformance (XML/HTTP Binding Support): An implementation MUST support the XML/HTTP binding. | true |  | false | technology | active | true
JAXWS:SPEC:11001 | 11 | 1.1.1 | Conformance (Incompatible handlers): An implementation MUST throw WebServiceException when, at the time a binding provider is created, the handler chain returned by the configured HandlerResolver contains an incompatible handler. | true |  | false | technology | active | false
JAXWS:SPEC:11002 | 11 | 1.1.1 | Conformance Requirement (Incompatible handlers): Implementations MUST throw a WebServiceException when attempting to configure an incompatible handler using Binding.setHandlerChain. | true |  | false | technology | active | false
JAXWS:SPEC:11003 | 11 | 1.1.1 | Conformance Requirement (Logical handler access): An implementation MUST allow access to the entire XML message via a logical message context. | true |  | false | technology | active | true
JAXWS:SPEC:11004 | 11 | 2.1.1 | A binding is responsible for catching runtime exceptions thrown by handlers and following the processing model described in section 9.3.2. A binding is responsible for converting the exception to a fault message subject to further handler processing if the following criteria are met: 1. A handler throws a ProtocolException from handleMessage, handleRequest or handleResponse 2. The MEP in use includes a response to the message being processed 3. The current message is not already a fault message (the handler might have undertaken the work prior to throwing the exception). If the above criteria are met then the exception is converted to a HTTP response message as follows: If the exception is an instance of HTTPException then the HTTP response code is set according to the value of the statusCode property. The current XML message content is removed. If the exception is of any other type then the HTTP status code is set to 500 to reflect a server class of error and any current XML message content is removed. "Handler processing is resumed as described in section 9.3.2. If the criteria for converting the exception to a fault message subject to further handler processing are not met then the exception is handled as follows depending on the current message direction: Outbound: The HTTP status code is set to 500 to reflect a server class of error, any current XML message content is removed and the message is dispatched. Inbound: The exception is passed to the binding provider. | true |  | false | technology | active | true
JAXWS:SPEC:11005 | 11 | 3.1 | Conformance Requirement (One-way operations): When invoking one-way operations, an implementation of the XML/HTTP binding MUST block until the HTTP response is received or an error occurs. | true |  | false | technology | active | true
JAXWS:SPEC:11006 | 11 | 3.2 | Conformance (HTTP basic authentication support): An implementation of the XML/HTTP binding MUST support HTTP basic authentication. | true |  | false | technology | active | true
JAXWS:SPEC:11007 | 11 | 3.2 | Conformance (Authentication properties): A client side implementation MUST support use of the the standard properties jakarta.xml.ws.security.auth.usernameand jakarta.xml.ws.security.auth.password to configure HTTP basic authentication. | true |  | false | technology | active | true
JAXWS:SPEC:11008 | 11 | 3.3 | Conformance Requirement (URL rewriting support): An implementation MUST support use of HTTP URL rewriting for state management. | true |  | false | technology | active | true
JAXWS:SPEC:11009 | 11 | 3.3 | Conformance Requirement (Cookie support): An implementation SHOULD support use of HTTP cookies for state management. | false |  | false | technology | active | true
JAXWS:SPEC:11010 | 11 | 3.3 | Conformance Requirement (SSL session support): An implementation MAY support use of SSL session based state management. | false |  | false | technology | active | true