Hi Guy,

Where exactly in your code do you need get access to the WS-A addressing
properties?

These are available via the
JAXWSAConstants.{CLIENT|SERVER}_ADDRESSING_PROPERTIES_{INBOUND|OUTBOUND}
properites in:

1. the request context available to the client application via
BindingProvider.getRequestContext()
2. the MessageContext passed JAX-WS Handlers
3. the Message passed to native CXF interceptor (of phase LOGICAL or
later in the chain)
4. the WebServiceContext that may be injected into the
implementor/servant code

The WS-A demo illustrates #1 and the WS-A system test has examples of #3
& #4. Approach #2 is very similar to #3, so could just clone the code in
the Handler demo.

On the issue of extracting WS-A information to/from existing XML
fragment ...

The WS-A interceptor which has responsibility for en/decoding WS-A
headers is the MAPCodec, which simply uses JAXB Marshaller/Unmarshaller
to write/read the WS-A stuff to/from an org.w3c.dom.Element representing
the headers. Now this code is not currently intended to be used
externally, but it could be fairly easily refactored so that MAPCodec
for example exposes public static utility methods like
encodeAddressingProperties()/decodeAddressingProperties() that could be
used to encode/decode to your DOM Element.

Cheers,
Eoghan

> -----Original Message-----
> From: Guy Pardon [mailto:[EMAIL PROTECTED] 
> Sent: 27 March 2007 12:16
> To: [email protected]
> Subject: Explicitly getting/setting WS-A information
> 
> Hi,
> 
> We need to have explicit access to WS-A addressing elements 
> like replyTo etc. since our SOAP ports are dynamically bound/exposed.
> 
> Also, we need to manipulate the WS-A data outside of the 
> typical message patterns, to support more complex 
> subscription patterns. This requires adding and extracting 
> WS-A information to and from existing XML fragments.
> 
> Are there any pointers on how to do this in CXF?
> 
> Thanks,
> Guy
> 

Reply via email to