[
https://issues.apache.org/jira/browse/SANDESHA2-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Parsons updated SANDESHA2-135:
-----------------------------------
Description:
The SandeshaModule has logic (see below) that checks the AxisOperations to see
if they are user operations. If they are it then adds a parameter to the
service if it is of type OutIn, that way when the createSeq msg is being built
it knows whether to add an offer. At present the code iterates through
AxisOperations and if it finds an AxisOperation that isn't a user defined
operation it breaks out of the loop. The problem with this is that the
AxisOperation just checked may not be the last. The fix to this is to change
the break statement to a continue statement.
The same bit of logic (see below) assumes that an AxisOperation with a default
OutIn name is not a user operation. This cannot be assumed and all we need to
filter are Sandesha AxisOperations. Therefore the fix is to remove the check
to see if the AxisOperation is of type default OutIn.
LOGIC:
if((name != null && name.startsWith(Sandesha2Constants.SANDESHA_OP_PREFIX)) ||
ServiceClient.ANON_OUT_IN_OP.equals(qName))
break;
Further to this issue a fix is needed in the CreateSeqMsgProcessor class. In
here there is some logic that builds the rMSBean when an offer has been sent
with the createSeq. With the above change you will get a NPE as it tries to
get the rmdBeans to endpt reference even if it is null. See attached patch for
complete fix.
was:
The SandeshaModule has logic (see below) that checks the AxisOperations to see
if they are user operations. If they are it then adds a parameter to the
service if it is of type OutIn, that way when the createSeq msg is being built
it knows whether to add an offer. At present the code iterates through
AxisOperations and if it finds an AxisOperation that isn't a user defined
operation it breaks out of the loop. The problem with this is that the
AxisOperation just checked may not be the last. The fix to this is to change
the break statement to a continue statement.
The same bit of logic (see below) assumes that an AxisOperation with a default
OutIn name is not a user operation. This cannot be assumed and all we need to
filter are Sandesha AxisOperations. Therefore the fix is to remove the check
to see if the AxisOperation is of type default OutIn.
LOGIC:
if((name != null && name.startsWith(Sandesha2Constants.SANDESHA_OP_PREFIX)) ||
ServiceClient.ANON_OUT_IN_OP.equals(qName))
break;
> Offers not being sent for RM 1.0 two way MEP's
> ----------------------------------------------
>
> Key: SANDESHA2-135
> URL: https://issues.apache.org/jira/browse/SANDESHA2-135
> Project: Sandesha2
> Issue Type: Bug
> Reporter: Dave Parsons
>
> The SandeshaModule has logic (see below) that checks the AxisOperations to
> see if they are user operations. If they are it then adds a parameter to the
> service if it is of type OutIn, that way when the createSeq msg is being
> built it knows whether to add an offer. At present the code iterates through
> AxisOperations and if it finds an AxisOperation that isn't a user defined
> operation it breaks out of the loop. The problem with this is that the
> AxisOperation just checked may not be the last. The fix to this is to change
> the break statement to a continue statement.
> The same bit of logic (see below) assumes that an AxisOperation with a
> default OutIn name is not a user operation. This cannot be assumed and all
> we need to filter are Sandesha AxisOperations. Therefore the fix is to
> remove the check to see if the AxisOperation is of type default OutIn.
> LOGIC:
> if((name != null && name.startsWith(Sandesha2Constants.SANDESHA_OP_PREFIX)) ||
> ServiceClient.ANON_OUT_IN_OP.equals(qName))
> break;
> Further to this issue a fix is needed in the CreateSeqMsgProcessor class. In
> here there is some logic that builds the rMSBean when an offer has been sent
> with the createSeq. With the above change you will get a NPE as it tries to
> get the rmdBeans to endpt reference even if it is null. See attached patch
> for complete fix.
--
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]
