Re: Overriding remotable
Raymond Feng wrote:
Hi,
At that time, I was questioning the merit to introduce remotable
attribute in the composite to override the Java interface. Really, to
make the service remotable, the interface design has to take that into
consideration upfront, especially the data model (for example, DTO
instead of an Object).
The rationale for this is that some Java interfaces can't be modified to
add SCA annotations, perhaps because they're in some standard spec or a
pre-existing framework library. However, these interfaces may have been
designed to have remotable semantics (SCA didn't invent remotability!)
Simon
Thanks,
Raymond
On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws simonsl...@googlemail.com
mailto:simonsl...@googlemail.com wrote:
On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
luckbr1...@gmail.com mailto:luckbr1...@gmail.com wrote:
On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
simonsl...@googlemail.com mailto:simonsl...@googlemail.com wrote:
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld
remotable=true/
binding.ws/ http://binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When
Helloworld looks like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to fix
but it leads to a question. In some of the databinding code
there are
tests for remotable which prevents further processing if an
interface
is not remotable. For example, DataBindingjavaInterfaceProcessor has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
http://tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
http://tuscanyinaction.com
It seems that there were some more issues around this (see [1])...
I'll try to dig out some more and see if I can remember little more
from when I was working on this in the past.
[1] http://tuscany.markmail.org/thread/nfzvrtrgrkdhqfkp
--
Luciano Resende
http://people.apache.org/~lresende
http://people.apache.org/%7Elresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Ok, that's interesting Luciano. So I don't loose it I added a patch to
(https://issues.apache.org/jira/browse/TUSCANY-3459) with the changes
required to make the infrastructure apply the remotable override. It
passes all the tests we have active at the moment.
I don't really understand Raymond's comment It seems to me that we
pretty much don't differentiate local and remote interfaces any more
with such changes from the thread you linked to. It's not clear
whether this is a comment about the aesthetics of having a flag with
which to affect the remotable status of an interface or a comment
suggesting that the infrastructure relies on there being no
databinding set for local interfaces. I can have a look at some local
tests to see if there is any spurious databinding processing going on.
Simon
--
Apache Tuscany committer: tuscany.apache.org http://tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
http://tuscanyinaction.com
[jira] [Assigned] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws reassigned TUSCANY-4017: --- Assignee: Simon Laws Tuscany needs to process profile intents as in OSOA --- Key: TUSCANY-4017 URL: https://issues.apache.org/jira/browse/TUSCANY-4017 Project: Tuscany Issue Type: Bug Components: Java SCA Policy Affects Versions: Java-SCA-2.0-Beta3 Reporter: Rashmi Hunt Assignee: Simon Laws Fix For: Java-SCA-2.x In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when I tried to get intent name from PolicySubject. In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany used to return it as 'atleastOnce'/'atMostOnce' as intent name ( PolicyComputationUtils.expandProfileIntents()) , which seems to be missing in OASIS implementation -- 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] [Commented] (TUSCANY-4017) Tuscany needs to process profile intents as in OSOA
[ https://issues.apache.org/jira/browse/TUSCANY-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13211771#comment-13211771 ] Simon Laws commented on TUSCANY-4017: - At revision: 1291186 I added a test case which looks at how the exactlyOnce profile intent resolves to atLeastOnce and atMostOnce in the endpoint. I need a bit more information about where in the code you were looking for the resolved intents. Tuscany needs to process profile intents as in OSOA --- Key: TUSCANY-4017 URL: https://issues.apache.org/jira/browse/TUSCANY-4017 Project: Tuscany Issue Type: Bug Components: Java SCA Policy Affects Versions: Java-SCA-2.0-Beta3 Reporter: Rashmi Hunt Assignee: Simon Laws Fix For: Java-SCA-2.x In OASIS Tuscany implementation, 'exactlyOnce' intent is returned as is when I tried to get intent name from PolicySubject. In OSOA Tuscany, if 'exactlyOnce' intent is defined in the composite, Tuscany used to return it as 'atleastOnce'/'atMostOnce' as intent name ( PolicyComputationUtils.expandProfileIntents()) , which seems to be missing in OASIS implementation -- 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] [Assigned] (TUSCANY-4016) NodeImpl startComposite forgets about a composite if there is a failure on start
[
https://issues.apache.org/jira/browse/TUSCANY-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws reassigned TUSCANY-4016:
---
Assignee: Simon Laws
NodeImpl startComposite forgets about a composite if there is a failure on
start
Key: TUSCANY-4016
URL: https://issues.apache.org/jira/browse/TUSCANY-4016
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
org.apache.tuscany.sca.impl.NodeImpl does the following on start
public void startComposite(String contributionURI, String compositeURI)
throws ActivationException, ValidationException, ContributionReadException {
String key = contributionURI+/+compositeURI;
if (startedComposites.containsKey(key)) {
throw new IllegalStateException(composite already started: +
compositeURI);
}
DeployedComposite dc = stoppedComposites.remove(key);
if (dc != null) {
dc.start();
startedComposites.put(key, dc);
and the following on stop
String key = contributionURI+/+compositeURI;
DeployedComposite dc = startedComposites.remove(key);
if (dc != null) {
dc.stop();
stoppedComposites.put(key, dc);
} else {
If an error is thrown on start it won't be in startedComposites but some of
the providers may have been started. So even in the failure case we should
consider the composite partially started so that it can be stopped correctly.
--
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: Overriding remotable
On Mon, Feb 20, 2012 at 10:19 AM, Simon Nash n...@apache.org wrote:
Raymond Feng wrote:
Hi,
At that time, I was questioning the merit to introduce remotable
attribute in the composite to override the Java interface. Really, to make
the service remotable, the interface design has to take that into
consideration upfront, especially the data model (for example, DTO instead
of an Object).
The rationale for this is that some Java interfaces can't be modified to
add SCA annotations, perhaps because they're in some standard spec or a
pre-existing framework library. However, these interfaces may have been
designed to have remotable semantics (SCA didn't invent remotability!)
Simon
Thanks,
Raymond
On Sat, Feb 18, 2012 at 9:15 AM, Simon Laws simonsl...@googlemail.com
mailto:simonsl...@googlemail.com wrote:
On Fri, Feb 17, 2012 at 6:08 PM, Luciano Resende
luckbr1...@gmail.com mailto:luckbr1...@gmail.com wrote:
On Fri, Feb 17, 2012 at 8:02 AM, Simon Laws
simonsl...@googlemail.com mailto:simonsl...@googlemail.com wrote:
In the OASIS spec you can override the remotable status of an
interface using the remotable flag on the interface element:
component name=HelloworldComponent
implementation.java class=sample.HelloworldImpl/
service name=HelloworldImpl
interface.java interface=sample.Helloworld
remotable=true/
binding.ws/ http://binding.ws/
/service
/component
The idea is that when Helloworld looks like
public interface Helloworld {
String sayHello(String name);
}
You can use the flag to set the interface remotable. When
Helloworld looks like
@Remotable
public interface Helloworld {
String sayHello(String name);
}
Then you can't use the flag to unset it.
There is a JIRA about this not working properly [1]. I've just been
looking at it. The problem is that we don't actually set remotable
based on this flag. This is a relatively straighforward thing to
fix
but it leads to a question. In some of the databinding code
there are
tests for remotable which prevents further processing if an
interface
is not remotable. For example, DataBindingjavaInterfaceProcessor
has
public void visitInterface(JavaInterface javaInterface) throws
InvalidInterfaceException {
if (!javaInterface.isRemotable()) {
return;
}
ListOperation operations = javaInterface.getOperations();
processInterface(javaInterface, operations);
}
This will run during introspection which is before we get to the
stage, in the builders, where the component and component type
interfaces are compared and where it would be sensible to apply the
override. I can make it work if I let this databinding processing
happen for non-remote interfaces just in case someone decides to
override them. Can anyone see a downside other than the extra
processing time it takes to calculate the interface types?
[1] https://issues.apache.org/jira/browse/TUSCANY-3459
Simon
--
Apache Tuscany committer: tuscany.apache.org
http://tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
http://tuscanyinaction.com
It seems that there were some more issues around this (see [1])...
I'll try to dig out some more and see if I can remember little more
from when I was working on this in the past.
[1] http://tuscany.markmail.org/thread/nfzvrtrgrkdhqfkp
--
Luciano Resende
http://people.apache.org/~lresende
http://people.apache.org/%7Elresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Ok, that's interesting Luciano. So I don't loose it I added a patch to
(https://issues.apache.org/jira/browse/TUSCANY-3459) with the changes
required to make the infrastructure apply the remotable override. It
passes all the tests we have active at the moment.
I don't really understand Raymond's comment It seems to me that we
pretty much don't differentiate local and remote interfaces any more
with such changes from the thread you linked to. It's not clear
whether this is a comment about the aesthetics of having a flag with
which to affect the remotable status of an interface or a comment
suggesting that the infrastructure relies on there being no
databinding set for local interfaces. I can have a look at some local
tests to see if there is any spurious databinding processing going on.
Simon
--
Apache Tuscany committer: tuscany.apache.org
http://tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
[jira] [Closed] (TUSCANY-3459) JSON-RPC (and other) binding fails if Interface is marked as remotable only in the composite
[
https://issues.apache.org/jira/browse/TUSCANY-3459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-3459.
---
Resolution: Fixed
I applied the patch at revision: 1291191 which should provide a general
solution to this by allowing the interface remotable status to be overriden.
JSON-RPC (and other) binding fails if Interface is marked as remotable only
in the composite
-
Key: TUSCANY-3459
URL: https://issues.apache.org/jira/browse/TUSCANY-3459
Project: Tuscany
Issue Type: Bug
Components: Java SCA Integration Tests
Affects Versions: Java-SCA-2.x
Reporter: Luciano Resende
Assignee: Luciano Resende
Fix For: Java-SCA-2.x
Attachments: 3459.patch
public interface Catalog {
Item[] get();
}
component name=VegetablesCatalog
implementation.java class=services.sca.FruitsCatalogImpl/
service name=Catalog
interface.java interface=services.Catalog
remotable=true/
tuscany:binding.jsonrpc
uri=http://localhost:8085/VegetableCatalog; /
/service
/component
at $Proxy7.get(Unknown Source)
at services.sca.CatalogAggregatorImpl.get(CatalogAggregatorImpl.java:40)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
org.apache.tuscany.sca.implementation.java.invocation.JavaImplementationInvoker.invoke(JavaImplementationInvoker.java:115)
at
org.apache.tuscany.sca.binding.sca.provider.SCABindingInvoker.invoke(SCABindingInvoker.java:61)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
at $Proxy7.get(Unknown Source)
at
org.apache.tuscany.sca.performance.CatalogRemoteJsonRPCTest.testCatalog(CatalogRemoteJsonRPCTest.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestDecorator.run(TestDecorator.java:32)
at junit.extensions.RepeatedTest.run(RepeatedTest.java:30)
at com.clarkware.junitperf.ThreadedTest$TestRunner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:637)
Caused by: org.jabsorb.serializer.UnmarshallException: element 0 no
serializer found that can unmarshall java.lang.String to services.Item
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:216)
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:692)
at org.jabsorb.client.Client.invoke(Client.java:226)
at org.jabsorb.client.Client.invoke(Client.java:156)
at
org.apache.tuscany.sca.binding.jsonrpc.provider.JSONRPCClientInvoker.invoke(JSONRPCClientInvoker.java:60)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:236)
at
org.apache.tuscany.sca.core.invocation.impl.JDKInvocationHandler.invoke(JDKInvocationHandler.java:106)
... 27 more
Caused by: org.jabsorb.serializer.UnmarshallException: no serializer found
that can unmarshall java.lang.String to services.Item
at org.jabsorb.JSONSerializer.unmarshall(JSONSerializer.java:705)
at
org.jabsorb.serializer.impl.ArraySerializer.unmarshall(ArraySerializer.java:209)
... 33 more
--
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-4016) NodeImpl startComposite forgets about a composite if there is a failure on start
[
https://issues.apache.org/jira/browse/TUSCANY-4016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws closed TUSCANY-4016.
---
Resolution: Fixed
Fix Version/s: Java-SCA-2.0
At revision: 1291234 I committed a fix and a test. On closer inspection it
turns out that we added code to the Activator a while back to stop providers if
there is a failure on start. So the extra stop added here may not do anything
but it won't do any harm. Moving the stopped composite to the stopped list does
allow the unused contributions to be unloaded if the appropriate operation is
called.
NodeImpl startComposite forgets about a composite if there is a failure on
start
Key: TUSCANY-4016
URL: https://issues.apache.org/jira/browse/TUSCANY-4016
Project: Tuscany
Issue Type: Bug
Components: SCA Java Runtime
Affects Versions: Java-SCA-2.0-Beta3
Environment: All
Reporter: Simon Laws
Assignee: Simon Laws
Fix For: Java-SCA-2.0
org.apache.tuscany.sca.impl.NodeImpl does the following on start
public void startComposite(String contributionURI, String compositeURI)
throws ActivationException, ValidationException, ContributionReadException {
String key = contributionURI+/+compositeURI;
if (startedComposites.containsKey(key)) {
throw new IllegalStateException(composite already started: +
compositeURI);
}
DeployedComposite dc = stoppedComposites.remove(key);
if (dc != null) {
dc.start();
startedComposites.put(key, dc);
and the following on stop
String key = contributionURI+/+compositeURI;
DeployedComposite dc = startedComposites.remove(key);
if (dc != null) {
dc.stop();
stoppedComposites.put(key, dc);
} else {
If an error is thrown on start it won't be in startedComposites but some of
the providers may have been started. So even in the failure case we should
consider the composite partially started so that it can be stopped correctly.
--
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-2735) Testing case where interface extends other that use Generics
[ https://issues.apache.org/jira/browse/TUSCANY-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-2735. --- Resolution: Fixed Fix Version/s: Java-SCA-2.0 Patch applied to 2.x at revision: 1291283. Thanks Rodolfo. Testing case where interface extends other that use Generics Key: TUSCANY-2735 URL: https://issues.apache.org/jira/browse/TUSCANY-2735 Project: Tuscany Issue Type: Test Components: Java SCA Integration Tests Affects Versions: Java-SCA-1.3.2 Environment: Ubuntu, Tuscany SCA 1.3.2, jrockit_150_11 Reporter: Rodolfo Dias Assignee: Rodolfo Dias Priority: Minor Fix For: Java-SCA-2.0, Java-SCA-2.x Attachments: ServicesTest.diff, itest-services-1.3.2-JIRA-2735.jar, itest-services-1.3.2-src-jira-2735.jar Project itest-service not test case where interface extends other that use Generics. -- 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-3859) tuscany generated wsdl: namespace prefix for the attribute base is missing
[ https://issues.apache.org/jira/browse/TUSCANY-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3859. --- I believe this is fixed now as I applied the 1.x/TUSCANY-3298 fixes to 2.x and took the WSDL verify tests from 1.x and added them to the wsdlgen itest on 2.x. tuscany generated wsdl: namespace prefix for the attribute base is missing Key: TUSCANY-3859 URL: https://issues.apache.org/jira/browse/TUSCANY-3859 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.6.1 Reporter: Antonio De Berardis Assignee: Simon Nash Fix For: Java-SCA-1.x I have a problem when I let tuscany generate the wsdl for a service. Namespace prefix for the attribute base is missing. If I have an object that extends another object, the schema generated should be: ... xs:complexType name=myObjChild xs:complexContent xs:extension base=tns:myObj ... but i got ... xs:complexType name=myObjChild xs:complexContent xs:extension base=myObj ... -- 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-3838) PolicyHandler.afterInvoke() is skipped when AxisFault occurs
[ https://issues.apache.org/jira/browse/TUSCANY-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Laws closed TUSCANY-3838. --- I believe this is fixed now. The policy runtime is slightly different in 2.x when compared to 1.x. In 2.x we have policy interceptors on the operation wire and on the binding wire and the binding wire providers get the opportunity to configure the binding. In the exception case the exception, wrapped in a Message object, should flow back along the wire and through the interceptors in the same way as a non-exception response does. PolicyHandler.afterInvoke() is skipped when AxisFault occurs Key: TUSCANY-3838 URL: https://issues.apache.org/jira/browse/TUSCANY-3838 Project: Tuscany Issue Type: Improvement Components: Java SCA Policy Affects Versions: Java-SCA-1.6 Environment: Windows 2003. Reporter: Gang Yang Assignee: Simon Nash Fix For: Java-SCA-1.x Attachments: code-snippet.txt When AxisFault is generated from invoking a remote service using WS binding, the reference side PolicyHandler.afterInvoke() is not called. -- 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
TUSCANY-4005 is in error
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 service-name 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.
[jira] [Updated] (TUSCANY-4018) JMS TransportServiceInterceptor using wrong values to set JMS headers in producer
[ https://issues.apache.org/jira/browse/TUSCANY-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jennifer A Thompson updated TUSCANY-4018: - Attachment: Tuscany-4018.patch 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 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
