Dan, Have a look at the ws_addressing demo, specifically the explicit propogation model.
Here the JAX-WS request context is used to associate a specific AddressingProperties instance with the invocation, in this case to use a particular message ID. Note however that setting the replyTo to a specific EPR won't cause the HTTP transport to start listening for decoupled responses on this URI. We've discussed this before on this list, and as you know the decoupled response endpoint is currently sepcified as part of the HTTPConduit config. Also as DanK points, the JAX-WS 2.1 subsumes JAX-WSA and provides a bunch of convenience APIs for WS-A, including a javax.xml.ws.EndpointReference type with a less ugly API than the JAXB generated type that you're complaining about. Instances of this type may be created via BindingProvider.getEndpointReference() and then used for example to retrieve a proxy via Service.getPort(EndpointReference epr, ...). Cheers, Eoghan > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED] > Sent: 27 February 2007 16:06 > To: [email protected] > Subject: Client API, EPRs > > Hi All, > > Is there a way to use WS-Adressing from the Client API? > Specifically I'd like to be able to set the replyTo/faultTo > locations somehow for the Client itself and then also on the > invocation context: > > client.setReplyTo(new EndpointReference("http://foo/replyTo";)); > > Or: > > Map<String, Object> context = ...; > context.put(REPLY_TO, epr); > client.invoke(operation, args, context); > > This brings up the question in my mind of whether or not we > really want to use EndpointReferenceType throughout the > codebase. I'm uncomfortable with the way things stand as > - EndpointRefenceType has an ugly API. It is not easy to > create an EPR from a String/URL and I think it should be > doable via a constructor. (Yeah, we can create factories, but > thats ugly and it still doesn't make retrieving values friendlier). > - We seem to have an odd mixture of EndpointReferenceTypes > and EndointInfos going on in our transport interfaces. On > some methods we require both. It seems like it should be > either one or the other. > - WIth that said, using an EndpointInfo is odd to me as thats > part of the service model. Using an EPR seems unnatural for > reasons I state above. > > Whats the advantage of using EndpointReferenceType throughout > the codebase as opposed to our own class? > > Regards, > - Dan > -- > Dan Diephouse > Envoi Solutions > http://envoisolutions.com | http://netzooid.com/blog >
