Create an instance of javax.xml.ws.AddressingFeature, using true as a constructor parameter. Then pass this feature instance to the port accessor method on the service stub you got from wsimport (or its equivalent). The code to do so looks like this:

new MyImplService().getMyImplPort(
	new javax.xml.ws.AddressingFeature(true)
);
						

The JAX-WS 2.1 specification indicates that clients must explicitly enable addressing in order to use addressing in a web service that declares support for it. For each invocation, the client must also explicitly set BindingProvider.SOAPACTION_URI_PROPERTY.

Example below shows how to use the AddressingFeature class with a service port object to enable WS-Addressing on the client:

import javax.xml.ws.soap.AddressingFeature;

public class AddressingClient {
    public static void main(String...args) {
        try { // Call Web Service Operation
            HelloAddressingWSService service = new HelloAddressingWSService();

            //enable WS-Addressing
            HelloAddressingWS port = service.getHelloAddressingWSPort(new AddressingFeature());

            String result = port.sayHello("Mikalai");
            System.out.println("Result = " + result);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}
						

So all you have to do is create a new AddressingFeature using the default constructor. There are two boolean arguments that you can optionally pass to the constructor as well, indicating preferences for "enabled" and "required":

    public AddressingFeature() {
        this.enabled = true;
    }

    public AddressingFeature(boolean enabled) {
        this.enabled = enabled;
    }

    /**
     * Create an AddressingFeature
     *
     * @param enabled specifies whether this feature should
     * be enabled or not.
     * @param 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.
     */
    public AddressingFeature(boolean enabled, boolean required) {
        this.enabled = enabled;
        this.required = required;
    }
						

blah-blah

The BindingProvider interface represents a component that provides a protocol binding for use by clients, it is implemented by proxies and is extended by the Dispatch interface.

Figure 12.1. BindingProvider Class Relationships

A web service client can get an javax.xml.ws.EndpointReference from a BindingProvider instance that will reference the target endpoint.

An implementation MUST be able to return an javax.xml.ws.EndpointReference for the target endpoint if a SOAP binding is being used. 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.

The returned W3CEndpointReference MUST contain wsam:ServiceName and wsam:ServiceName[@EndpointName] as per Addressing 1.0 Metadata. 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.

Proxies provide access to service endpoint interfaces at runtime without requiring static generation of a stub class. See java.lang.reflect.Proxy for more information on dynamic proxies as supported by the JDK. 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.

An instance of a proxy MUST implement javax.xml.ws.BindingProvider.

A proxy is created using the getPort methods of a Service instance:

The use of WS-Addressing requirements can be indicated in a WSDL as per Addressing 1.0 - Metadata. A proxy created using getPort() calls is configured with the addressing requirements as specified in the associated WSDL or explicitly passing javax.xml.ws.soap.AddressingFeature web service feature.

A proxy MUST be configured with the use of addressing requirements as indicated in the associated WSDL. But if the proxy is created using javax.xml.ws.soap.AddressingFeature web service feature, the feature's addressing requirements MUST take precedence over WSDL's addressing requirements.

Client example:

public class Client {

	@WebServiceRef
	static AddNumbersService service;

	private WebServiceFeature[] enabledRequiredwsf = { new AddressingFeature(true, true) };

	AddNumbers port;

	private AddNumbers getPort() {
		port = service.getPort(AddNumbers.class, enabledRequiredwsf);
		return port;
	}
	...