javax.xml.ws.soap

## Class AddressingFeature

- java.lang.Object
- - javax.xml.ws.WebServiceFeature
  - - javax.xml.ws.soap.AddressingFeature

-     public final class AddressingFeature
      extends WebServiceFeature

  This feature represents the use of WS-Addressing with either the SOAP 1.1/HTTP or SOAP 1.2/HTTP binding. Using this feature with any other binding is NOT required.

  Enabling this feature on the client will cause the JAX-WS runtime to include WS-Addressing headers in SOAP messages.

  If the web service developer has not explicitly enabled this feature, it MAY be automatically enabled if the associated WSDL enables WS-Addressing with an implementation recognized WSDL extension element. However, in this version of JAX-WS, there is no standard WSDL extension that a client can rely on to automatically enable WS-Addressing, nor is there a standard default value specified for WS-Addressing `Action` headers.

  To write a portable endpoint and its corresponding client with this version of JAX-WS, an endpoint MUST explicitly specify what WS-Addressing `Actions` are to be used via the `Action` and `FaultAction` annotations. The client MUST explicitly enable addresssing via this `AddressingFeature`, and for each invocation, the client MUST explicitly set the `BindingProvider.SOAPACTION_URI_PROPERTY`. After the W3C WG on WS-Addressing has specified how the use of WS-Addressing is specified in the WSDL, and what the default value must be for Action headers, a future version of JAX-WS will remove these requirements.

  See `RespectBindingFeature` for more information on required WSDL extensions.

  The following describes the effects of this feature with respect to be enabled or disabled:

  - ENABLED: In this Mode, WS-Addressing will be enabled. At runtime, WS-Addressing headers MUST be consumed by the receiver and produced by the sender even if the WSDL declares otherwise. The mustUnderstand="0" attribute MUST be used on the WS-Addressing headers.
  - DISABLED: In this Mode, WS-Addressing will be disabled even if an associated WSDL specifies otherwise. At runtime, WS-Addressing headers MUST NOT be used. WS-Addressing may be explicitly disabled to prevent a JAX-WS implementation from consuming and producing WS-Addressing headers. If an application has implemented WS-Addressing itself, it MUST explicitly disable this feature. Not doing so may break compatibility with future versions of JAX-WS.

  The `required` property can be used to specify if WS-Addressing headers MUST be present on incoming messages. This property only has meaning when used on the endpoint and has no affect when used on the client. By default the `required` property is `false`.

  See Web Services Addressing - Core and Web Services Addressing 1.0 - SOAP Binding for more information on WS-Addressing.

  Since:
    JAX-WS 2.1

- - ### Field Summary

    Fields
    Modifier and Type | Field and Description
    --- | ---
    `static String` | `ID` Constant value identifying the AddressingFeature
    `protected boolean` | `required` Property for the `required` feature parameter.

    - ### Fields inherited from class javax.xml.ws.WebServiceFeature

      `enabled`

  - ### Constructor Summary

    Constructors
    Constructor and Description
    `AddressingFeature()` Create an `AddressingFeature`.
    `AddressingFeature(boolean enabled)` Create an `AddressingFeature`
    `AddressingFeature(boolean enabled, boolean required)` Create an `AddressingFeature`

  - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `String` | `getID()` Get the unique identifier for this WebServiceFeature.
    `boolean` | `isRequired()` Gets the boolean value used to determine if WS-Addressing headers MUST be present on incoming messages.

    - ### Methods inherited from class javax.xml.ws.WebServiceFeature

      `isEnabled`

    - ### Methods inherited from class java.lang.Object

      `clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

- - ### Field Detail

    - #### ID

          public static final String ID

      Constant value identifying the AddressingFeature
      See Also:
        Constant Field Values

    - #### required

          protected boolean required

      Property for the `required` feature parameter. When WS-Addressing is enabled, the value of this property will be used to specify if WS-Addressing headers MUST be present on incoming messages. This property only has meaning on the endpoint and has no affect when used on the client.

  - ### Constructor Detail

    - #### AddressingFeature

          public AddressingFeature()

      Create an `AddressingFeature`. The instance created will be enabled.

    - #### AddressingFeature

          public AddressingFeature(boolean enabled)

      Create an `AddressingFeature`
      Parameters:
        `enabled` - specifies whether this feature should be enabled or not.

    - #### AddressingFeature

          public AddressingFeature(boolean enabled,
                           boolean required)

      Create an `AddressingFeature`
      Parameters:
        `enabled` - specifies whether this feature should be enabled or not.
        `required` - specifies whether WS-Addressing headers MUST be present on incoming messages. This property only has meaning on the endpoint and has no affect when used on the client.

  - ### Method Detail

    - #### getID

          public String getID()

      Get the unique identifier for this WebServiceFeature.
      Specified by:
        `getID` in class `WebServiceFeature`
      Returns:
        the unique identifier for this feature.

    - #### isRequired

          public boolean isRequired()

      Gets the boolean value used to determine if WS-Addressing headers MUST be present on incoming messages. This property only has meaning on the endpoint, and has no affect when used on the client.
      Returns:
        the current required value

Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.

Copyright © 1993, 2014, Oracle and/or its affiliates. All rights reserved.