[
https://issues.apache.org/jira/browse/TUSCANY-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Nash updated TUSCANY-1591:
--------------------------------
Attachment: patch1591
I'm attaching a patch to fix this problem. It contains the following changes:
1. Rewrote the code in Axis2BindingInvoker to fix the duplicate wsa:From
problem reported by this JIRA when using conversations without callbacks, and
also to support using conversations and callbacks together (stateful callbacks).
2. Rewrote the code in Axis2ServiceProvider,
Axis2ServiceInOutSyncMessageReceiver and Axis2ServiceInMessageReceiver to
consolidate the reading of all WS-Addressing header information in a single
method, and throw exceptions if there are any missing, incorrect or duplicated
elements.
3. Added support in Axis2BindingInvoker and Axis2ServiceProvider for passing
the callback ID in the WS-Addressing headers.
4. Changed Axis2BindingInvoker and Axis2ReferenceBindingProvider to only take
"From" infomation from the message context, removing the separate code to take
this from the callback binding information in the model. (If this model
information is present, it will still be accessed via the message context.)
5. Changed Axis2BindingInvoker to take the callback ID from the recently added
callableReference field in the message context, instead of from the
correlationID field. (Note: I did not make the corresponding change in
Axis2ServiceProvider, because there is no callable reference object available
when this information is deserialized from the wire. We need to decide what
mechanism to use on the service side to hold the callback ID and the
conversation ID. Creating a callable reference object specially to hold this
information seems unreasonably expensive.)
6. Changed the core invocation framework to put a callable reference in the
message context when invoking callbacks using JDKCallbackInvocationHandler.
(This was previously set to null.) This is needed to hold the callback ID and
conversation ID for the callback, assuming that we decide to use this approach.
It also brings callback invocations closer in line with forward invocations.
> Duplicate <wsa:From> added to SOAP Header when using conversational interface
> ------------------------------------------------------------------------------
>
> Key: TUSCANY-1591
> URL: https://issues.apache.org/jira/browse/TUSCANY-1591
> Project: Tuscany
> Issue Type: Bug
> Reporter: Lou Amodeo
> Assignee: Simon Nash
> Fix For: Java-SCA-1.0
>
> Attachments: patch1591
>
>
> I just ran into this problem that appears to be a result of the changes to
> support callback. I believe the problem occurs when there is a
> conversational interface and two <wsa:From> elements are being generated in
> Axis2BindingInvoker.java when if (conversationId != null &&
> conversationId.length() != 0) is true in createOperationClient(Object[]
> args, String conversationId). Note, There is no callback involved here. It
> looks like changes added to support calbacks intorduced creating a 2nd
> <wsa:From> when conversational interface is used.
> <?xml version="1.0" encoding="utf-8"?>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
> <soapenv:Header>
> <wsa:From xmlns:wsa="http://www.w3.org/2005/08/addressing">
>
> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
> <wsa:ReferenceParameters></wsa:ReferenceParameters>
> </wsa:From>
> <wsa:From xmlns:wsa="http://www.w3.org/2005/08/addressing">
>
> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
> <wsa:ReferenceParameters>
> <axis2ns13:conversationID
> xmlns:axis2ns13="http://www.osoa.org/xmlns/sca/1.0">
> d96deb50-cf30-4c5c-a381-d0b0ab19bf74
> </axis2ns13:conversationID>
> </wsa:ReferenceParameters>
> </wsa:From>
> </soapenv:Header>
> <soapenv:Body>
> <scaNS:add xmlns:scaNS="http://components.ws.bindings.sca.test">
> <scaNS:param0>1</scaNS:param0></scaNS:add>
> </soapenv:Body>
>
> </soapenv:Envelope>
> org.apache.axis2.AxisFault: A header representing a Message Addressing
> Property is not valid and the message cannot be processed
> at
> org.apache.axis2.addressing.AddressingFaultsHelper.triggerAddressingFault(AddressingFaultsHelper.java:379)
> at
> org.apache.axis2.addressing.AddressingFaultsHelper.triggerInvalidCardinalityFault(AddressingFaultsHelper.java:158)
> at
> org.apache.axis2.handlers.addressing.AddressingInHandler.extractAddressingInformation(AddressingInHandler.java:193)
> at
> org.apache.axis2.handlers.addressing.AddressingInHandler.invoke(AddressingInHandler.java:98)
> at org.apache.axis2.engine.Phase.invoke(Phase.java:379)
> at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:287)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:204)
> at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:271)
> at
> com.ibm.ws.websvcs.transport.http.WASAxis2Servlet.doPost(WASAxis2Servlet.java:907)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
> at
> com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:995)
> at
> com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:501)
> at
> com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:464)
> at
> com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)
> at
> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
> at
> com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1439)
> at
> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:112)
> at
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:454)
> at
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:383)
> at
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:263)
> at
> com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
> at
> com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
> at
> com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
> at
> com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
> at
> com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
> at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
> at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195)
> at
> com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743)
> at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
> at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]