Hi Eoghan, I'm a bit concerned about having to set this on the HTTPConduit (or its configuration). This seems to force the user to always be involved in setting up the decoupled endpoint as there is no standard way across transports to set up the decoupled channel.
Lets say I embed CXF in another product and I need to configure via the API the ReplyTo EPR for sequence acknowledgements. Now my product needs to be aware of each and every transport that supports decoupling and how to set up the decoupled response channel. i.e. HTTPClientPolicy.setDecoupledEndpoint(...); on each transport. Couldn't we make a generic way for people to specify the ReplyTo EPR and let CXF take care of the rest? By "the rest" I mean that CXF would set up the decoupled response listener with just the knowledge of my EPR. Or am I missing something here? - Dan On 2/27/07, Glynn, Eoghan <[EMAIL PROTECTED]> wrote:
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 >
-- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
