How do I set WS-Addressing ReplyTo header to NON-anonymous value

[khan gul]

Hi,
I am breaking my head to find out how I can set the ReplyTo value programatically. i searched everywhere without any answer. Can any know how to do this?

All I need is to change this the address http://www.w3.org/2005/08/addressing/anonymous as shown below

<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
</ReplyTo>

to something like this:


<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.myservice.com/invoke</Address>
</ReplyTo>

[Ivan Krizsan]

Hi!
Have you tried modifying the ReplyTo address in a handler that processes outgoing messages?
Best wishes!

[khan gul]

Are you trying to say generate the whole header manually? So if I understand you correctly what you are saying is get the SOAPMessage from the handler and then add new header with all those attribute. Is it correct?
This is very tidous. What I am trying to do is something like this:

//Define your call back class to which the final reply from the server should come

javax.xml.ws.Endpoint e = Endpoint.publish( "http://127.0.0.1:9999/ts", new HelloCallback());

WSEndpointReference replyTo = new WSEndpointReference(e.getEndpointReference());

//Then set this replyTo as a OneWayFeature in the current service request

Hello hello = helloService.getHelloPort(new WebServiceFeature[] { new OneWayFeature(true, replyTo)});

//invoke the service
hello.sayHello("Bob");


The problem with the above is that when I send the request I am getting the following error:

28-Jul-2011 9:22:32 AM com.sun.xml.internal.ws.model.RuntimeModeler getRequestWrapperClass
INFO: Dynamically creating request wrapper Class project1.jaxws.SayHello
28-Jul-2011 9:22:32 AM com.sun.xml.internal.ws.model.RuntimeModeler getResponseWrapperClass
INFO: Dynamically creating response wrapper bean Class project1.jaxws.SayHelloResponse
javax.xml.ws.WebServiceException: java.io.IOException: Stream is closed
at com.sun.xml.internal.ws.streaming.TidyXMLStreamReader.close(TidyXMLStreamReader.java:58)
at com.sun.xml.internal.ws.server.sei.EndpointArgumentsBuilder$DocLit.readRequest(EndpointArgumentsBuilder.java:524)
at com.sun.xml.internal.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:232)
at com.sun.xml.internal.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:82)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)


I read somewhere that if you use JDK1.6.0.6 then its a known bug. But I am using jdk1.6.0.26 and still see this problem.

Can anyone share his or her code regarding the above
regards,
arslan

[Ivan Krizsan]

Hi!
Is it possible to use reply-to with a one-way operation, which will never have a response?
That could explain why the stream is already closed when an attempt at sending the response is done.
By the way, if you look at the JavaDoc for OneWayFeature, you can read:

Unsupported RI extension to work around an issue in WSIT.
This feature is not meant to be used by a common Web service developer as there is no need to send the above mentioned header for a one-way operation. But these properties may need to be sent in certain middleware Web services.

Best wishes!

[khan gul]

I my opinion there is a strong case for sending one way message with replyTo header. Here is the detail:

Client 1 wants to send a message to Server1 with the intend to get back the response on another URL i.e client2. So the question is how Client 1 can send the message? I can only think of that client1 will send the message as ONEWAY and will recieve an HTTP Response 202. Server 1 will read the replyTo header and send the response to client 2.

Not sure how can we do that if what you are saying is correct. Any idea?

[Ivan Krizsan]

Hi!
I think it is not a good idea to mix the behaviour of the transport protocol used, in this case (and quite often) HTTP, with the behaviour of SOAP and SOAP-related extensions.
A server may send a redirect without knowing anything about the contents of the data enclosed in the request. Thus I suspect that no matter what you send in a SOAP message, the server will, if using HTTP, send a redirect response to the address in the HTTP request (in the TCP data?) and ignore the WS-Addressing data.
SOAP is supposed to be independent of the transport protocol, so you cannot rely on HTTP being used.

An alternative approach for you may be to use a handler that examines incoming responses. If it is a redirect, then it examines the SOAP message for a WS-Addressing ReplyTo address and redirects the response there. Can't say I have tried this approach, so I would be curious to know the result if you decide to try.
Best wishes!