[jira] [Updated] (TUSCANY-4019) scaOperationName being set on response messages

2012-02-21 Thread Jennifer A Thompson (Updated) (JIRA)

 [ 
https://issues.apache.org/jira/browse/TUSCANY-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jennifer A Thompson updated TUSCANY-4019:
-

Attachment: Tuscany-4019.patch

> scaOperationName being set on response messages
> ---
>
> Key: TUSCANY-4019
> URL: https://issues.apache.org/jira/browse/TUSCANY-4019
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA JMS Binding Extension
>Affects Versions: Java-SCA-2.x
>Reporter: Jennifer A Thompson
> Fix For: Java-SCA-2.x
>
> Attachments: Tuscany-4019.patch
>
>
> Per the JMS Binding specification,  scaOperationName should be set when 
> "receiving a request at a service, or a callback at a reference" 
> (line399-400), so it should not be set for reply messages. However the 
> HeaderServiceInterceptor.processResponse message is calling:
> responseMessageProcessor.setOperationName(operationName, jmsMsg);
> Which sets the scaOperationName of the request in the response message. This 
> line should be removed.

--
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




[jira] [Created] (TUSCANY-4019) scaOperationName being set on response messages

2012-02-21 Thread Jennifer A Thompson (Created) (JIRA)
scaOperationName being set on response messages
---

 Key: TUSCANY-4019
 URL: https://issues.apache.org/jira/browse/TUSCANY-4019
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA JMS Binding Extension
Affects Versions: Java-SCA-2.x
Reporter: Jennifer A Thompson
 Fix For: Java-SCA-2.x


Per the JMS Binding specification,  scaOperationName should be set when 
"receiving a request at a service, or a callback at a reference" (line399-400), 
so it should not be set for reply messages. However the 
HeaderServiceInterceptor.processResponse message is calling:

responseMessageProcessor.setOperationName(operationName, jmsMsg);

Which sets the scaOperationName of the request in the response message. This 
line should be removed.

--
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




[jira] [Closed] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer

2012-02-21 Thread Simon Laws (Closed) (JIRA)

 [ 
https://issues.apache.org/jira/browse/TUSCANY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws closed TUSCANY-4018.
---

Resolution: Fixed

Committed at revision: 1291715. Thanks for the patch Jennifer.

> JMS TransportServiceInterceptor using wrong values to set JMS headers in 
> producer
> -
>
> Key: TUSCANY-4018
> URL: https://issues.apache.org/jira/browse/TUSCANY-4018
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA JMS Binding Extension
>Affects Versions: Java-SCA-2.x
>Reporter: Jennifer A Thompson
>Assignee: Simon Laws
> Fix For: Java-SCA-2.x
>
> Attachments: Tuscany-4018.patch
>
>
> In TransportServiceInterceptor.invokeResponse is setting the effective 
> TimeToLive, Priority in the response message, but when the values are set in 
> the producer, the values from the request are used, potentially leading to an 
> incorrect value. So the following:
>  // Set jms header attributes in producer, not message.
> int deliveryMode = requestJMSMsg.getJMSDeliveryMode();
> producer.setDeliveryMode(deliveryMode);
> int deliveryPriority = requestJMSMsg.getJMSPriority();
> producer.setPriority(deliveryPriority);
> long timeToLive = requestJMSMsg.getJMSExpiration();
> producer.setTimeToLive(timeToLive);
> Should be:
> // Set jms header attributes in producer, not message.
> producer.setDeliveryMode(responseJMSMsg.getJMSDeliveryMode());
> producer.setPriority(responseJMSMsg.getJMSPriority());
> producer.setTimeToLive(responseJMSMsg.getJMSExpiration());

--
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




Re: TUSCANY-4005 is in error

2012-02-21 Thread Simon Laws
On Tue, Feb 21, 2012 at 10:04 AM, Simon Laws  wrote:
> On Mon, Feb 20, 2012 at 7:03 PM, Greg Dritschler
>  wrote:
>> I believe the fix for TUSCANY-4005 is in error.  The goal of the fix was to
>> comply with this requirement:
>>
>> The target component has multiple services. According to the following text
>> in the assembly specification, the target component must have one and only
>> one service with a compatible interface.
>>
>>  1844 If  is not present, the target component MUST have one
>> and only
>>  1845 one service with an interface that is a compatible superset of the
>> wire source's
>>  1845 interface and satisifies the policy requirements of the wire source,
>> and the SCA
>>  1846 runtime MUST use this service for the wire. [ASM60048]
>>
>> The fix checks if there are multiple candidate targets BEFORE DOING ANY
>> FILTERING for interface compatibility or policy matching.  If the target
>> does have one and only one service with a compatible interface and policy,
>> you now get the error introduced by the fix.  This was not the intention.
>
> My mistake, let me switch the test around.
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Change applied at r1291714

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com


[jira] [Assigned] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer

2012-02-21 Thread Simon Laws (Assigned) (JIRA)

 [ 
https://issues.apache.org/jira/browse/TUSCANY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Laws reassigned TUSCANY-4018:
---

Assignee: Simon Laws

> JMS TransportServiceInterceptor using wrong values to set JMS headers in 
> producer
> -
>
> Key: TUSCANY-4018
> URL: https://issues.apache.org/jira/browse/TUSCANY-4018
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA JMS Binding Extension
>Affects Versions: Java-SCA-2.x
>Reporter: Jennifer A Thompson
>Assignee: Simon Laws
> Fix For: Java-SCA-2.x
>
> Attachments: Tuscany-4018.patch
>
>
> In TransportServiceInterceptor.invokeResponse is setting the effective 
> TimeToLive, Priority in the response message, but when the values are set in 
> the producer, the values from the request are used, potentially leading to an 
> incorrect value. So the following:
>  // Set jms header attributes in producer, not message.
> int deliveryMode = requestJMSMsg.getJMSDeliveryMode();
> producer.setDeliveryMode(deliveryMode);
> int deliveryPriority = requestJMSMsg.getJMSPriority();
> producer.setPriority(deliveryPriority);
> long timeToLive = requestJMSMsg.getJMSExpiration();
> producer.setTimeToLive(timeToLive);
> Should be:
> // Set jms header attributes in producer, not message.
> producer.setDeliveryMode(responseJMSMsg.getJMSDeliveryMode());
> producer.setPriority(responseJMSMsg.getJMSPriority());
> producer.setTimeToLive(responseJMSMsg.getJMSExpiration());

--
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




Re: TUSCANY-4005 is in error

2012-02-21 Thread Simon Laws
On Mon, Feb 20, 2012 at 7:03 PM, Greg Dritschler
 wrote:
> I believe the fix for TUSCANY-4005 is in error.  The goal of the fix was to
> comply with this requirement:
>
> The target component has multiple services. According to the following text
> in the assembly specification, the target component must have one and only
> one service with a compatible interface.
>
>  1844 If  is not present, the target component MUST have one
> and only
>  1845 one service with an interface that is a compatible superset of the
> wire source's
>  1845 interface and satisifies the policy requirements of the wire source,
> and the SCA
>  1846 runtime MUST use this service for the wire. [ASM60048]
>
> The fix checks if there are multiple candidate targets BEFORE DOING ANY
> FILTERING for interface compatibility or policy matching.  If the target
> does have one and only one service with a compatible interface and policy,
> you now get the error introduced by the fix.  This was not the intention.

My mistake, let me switch the test around.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com