[
https://issues.apache.org/jira/browse/TUSCANY-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws resolved TUSCANY-2987.
---------------------------------
Resolution: Fixed
Fix Version/s: Java-SCA-Next
> Sort out jms operation selector mapping to service operations
> -------------------------------------------------------------
>
> Key: TUSCANY-2987
> URL: https://issues.apache.org/jira/browse/TUSCANY-2987
> Project: Tuscany
> Issue Type: Improvement
> Components: Java SCA JMS Binding Extension
> Affects Versions: Java-SCA-1.4
> Environment: All
> Reporter: Simon Laws
> Fix For: Java-SCA-Next
>
>
> There are two parts to this
> First, the code for nativeOperation handling is in the wrong place. It's in
> the reference side rather than the service side. I.e. the
> HeaderReferenceInterceptor shouldn't be trying to do anything with it.
> What I believe should happen is that in the service side operation selector
> we should...
> generate an operation name as defined in the default operation selector
> algorithm in the spec
> use this operation name to locate an operation properties using the
> operationProperties/@name attirbute
> use this operationProperties/@nativeOperation attribute to find the real
> operation to call.
> It seems useful to show how to generate a new, non-default operation
> selector, to allow the user to specific which propery in the message the
> operation name will be pulled. This is not defined in the specification. But
> is does motivate us to put the native operation processing in a separate
> interceptor so that regardless of which operation selector is used to choose
> the operation name the same nativeOperation processing can be applied
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
