You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Gary Tully (JIRA)" <ji...@apache.org> on 2007/01/26 17:33:49 UTC
[jira] Created: (CXF-393) All JMS message properties are always
copied from source to destination
All JMS message properties are always copied from source to destination
-----------------------------------------------------------------------
Key: CXF-393
URL: https://issues.apache.org/jira/browse/CXF-393
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 2.0-M1
Reporter: Gary Tully
Some JMS implementations are strict about the setting of properties. The properties valid on an incomming message are not valid for an outgoing message. CXF by default will copy all message properties from the input message to request headers and copy the headers to a reply. This can lead to failure to send reply messages. For example JMSX properties that indicate a message is a needs a reply have no business themselves in a reply.
The fix would allow an exclued filter be specified on property read such that a set of known request propertys can be omitted/excluded from the headers. This could be applied on either the getter or setter. Since the setter is typically where the problem arises, limiting the JMS properties that can be set may be the best solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-393) All JMS message properties are always
copied from source to destination
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469446 ]
Gary Tully commented on CXF-393:
--------------------------------
It looks like the auto copy semantics of the JMS transport are wrong. JMSConstants.JMS_SERVER_HEADERS should be broken into JMS_SERVER_REQUEST_HEADERS and JMS_SERVER_RESPONSE_HEADERS and never the two should meet. The application would need to set a custom property in the RESPONSE header if it needs it in a reply. This would require org.apache.cxf.systest.jms.GreeterImplTwoWayJMS to do some more work to ensure a property is in a reply. Is this ok?
The JMSDestination will deal with replyTo and Correlation, but all other properties from a request disappear into the eather once the request has been dispatched. They should not be auto copied into the reply.
> All JMS message properties are always copied from source to destination
> -----------------------------------------------------------------------
>
> Key: CXF-393
> URL: https://issues.apache.org/jira/browse/CXF-393
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.0-M1
> Reporter: Gary Tully
>
> Some JMS implementations are strict about the setting of properties. The properties valid on an incomming message are not valid for an outgoing message. CXF by default will copy all message properties from the input message to request headers and copy the headers to a reply. This can lead to failure to send reply messages. For example JMSX properties that indicate a message is a needs a reply have no business themselves in a reply.
> The fix would allow an exclued filter be specified on property read such that a set of known request propertys can be omitted/excluded from the headers. This could be applied on either the getter or setter. Since the setter is typically where the problem arises, limiting the JMS properties that can be set may be the best solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-393) All JMS message properties are always
copied from source to destination
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully resolved CXF-393.
----------------------------
Resolution: Fixed
Fix Version/s: 2.0-RC
fixed via http://svn.apache.org/viewvc?view=rev&rev=503780
> All JMS message properties are always copied from source to destination
> -----------------------------------------------------------------------
>
> Key: CXF-393
> URL: https://issues.apache.org/jira/browse/CXF-393
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.0-M1
> Reporter: Gary Tully
> Fix For: 2.0-RC
>
> Attachments: cxf-393.rel.patch
>
>
> Some JMS implementations are strict about the setting of properties. The properties valid on an incomming message are not valid for an outgoing message. CXF by default will copy all message properties from the input message to request headers and copy the headers to a reply. This can lead to failure to send reply messages. For example JMSX properties that indicate a message is a needs a reply have no business themselves in a reply.
> The fix would allow an exclued filter be specified on property read such that a set of known request propertys can be omitted/excluded from the headers. This could be applied on either the getter or setter. Since the setter is typically where the problem arises, limiting the JMS properties that can be set may be the best solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-393) All JMS message properties are always
copied from source to destination
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467854 ]
Gary Tully commented on CXF-393:
--------------------------------
possibly a good fix it to provide a regular expression in config that is used (if present) to gate the setting of properties.
> All JMS message properties are always copied from source to destination
> -----------------------------------------------------------------------
>
> Key: CXF-393
> URL: https://issues.apache.org/jira/browse/CXF-393
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.0-M1
> Reporter: Gary Tully
>
> Some JMS implementations are strict about the setting of properties. The properties valid on an incomming message are not valid for an outgoing message. CXF by default will copy all message properties from the input message to request headers and copy the headers to a reply. This can lead to failure to send reply messages. For example JMSX properties that indicate a message is a needs a reply have no business themselves in a reply.
> The fix would allow an exclued filter be specified on property read such that a set of known request propertys can be omitted/excluded from the headers. This could be applied on either the getter or setter. Since the setter is typically where the problem arises, limiting the JMS properties that can be set may be the best solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-393) All JMS message properties are always
copied from source to destination
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully updated CXF-393:
---------------------------
Attachment: cxf-393.rel.patch
this patch removes the automatic copying of JMS message string properties from request context to reply context. JMS_SERVER_HEADERS is now replaced with JMS_SERVER_REQUEST_HEADERS. JMS_SERVER_RESPONSE_HEADERS can be modified to include properties in the reply.
> All JMS message properties are always copied from source to destination
> -----------------------------------------------------------------------
>
> Key: CXF-393
> URL: https://issues.apache.org/jira/browse/CXF-393
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 2.0-M1
> Reporter: Gary Tully
> Attachments: cxf-393.rel.patch
>
>
> Some JMS implementations are strict about the setting of properties. The properties valid on an incomming message are not valid for an outgoing message. CXF by default will copy all message properties from the input message to request headers and copy the headers to a reply. This can lead to failure to send reply messages. For example JMSX properties that indicate a message is a needs a reply have no business themselves in a reply.
> The fix would allow an exclued filter be specified on property read such that a set of known request propertys can be omitted/excluded from the headers. This could be applied on either the getter or setter. Since the setter is typically where the problem arises, limiting the JMS properties that can be set may be the best solution.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.