Should new wsa:MessageID be constructed on binding.ws reference callback
invocation?
------------------------------------------------------------------------------------
Key: TUSCANY-3994
URL: https://issues.apache.org/jira/browse/TUSCANY-3994
Project: Tuscany
Issue Type: Bug
Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-2.x
Reporter: Scott Kurz
Priority: Minor
I noticed in Axis2ReferenceBindingInvoker.createOperationClient(Message msg)
we do:
if (callbackEndpoint != null) {
....
addWSAMessageIDHeader( sh,
(String)msg.getHeaders().get("MESSAGE_ID"));
It seems there are two problems with this:
1) We aren't always going to have a MESSAGE_ID header in the Tuscany message.
This is a problem if, say, Axis2's addressing module is enabled, in which case
the appearance of any WSA headers is going to imply that wsa:MessageID must
appear (except for in-only operations).
2) If the MESSAGE_ID is set, should we be propagating it? Sure there could be
some value in a propagated ID, but is this what is done with wsa:MessageID?
Not fully grasping all the details of our async invocation support, I'm viewing
the message id as the id for this message, which may be set in the service
binding when an incoming request and seemingly then copied on through to the
reference binding invocation. So it's a correlation id of sorts within this
JVM for a bigger scope than just one binding->impl dispatch.... but I don't
think it should have a larger lifetime extending to other requests downstream.
Does that make sense? Is there a better approach?
Such a code patch would be easy.. I just wanted to write this up to see if it
makes sense.
Thanks,
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
