You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Simon Laws (JIRA)" <de...@tuscany.apache.org> on 2009/04/24 19:47:30 UTC
[jira] Created: (TUSCANY-2987) Sort out jms operation selector
mapping to service operations
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
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.
[jira] Resolved: (TUSCANY-2987) Sort out jms operation selector
mapping to service operations
Posted by "Simon Laws (JIRA)" <de...@tuscany.apache.org>.
[ 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.