[
https://issues.apache.org/activemq/browse/SM-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41924#action_41924
]
rgavlin edited comment on SM-1238 at 3/31/08 12:48 AM:
----------------------------------------------------------
Just to be clear, one of my representative use cases is as follows:
EIP StaticRecipientList -> 1. Saxon -> 1. Pipeline (transformer = HTTP BC
provider) -> 1./2. RecipientListAggregator -> Saxon
Here, I need the properties added by the StaticRecipientList to pass through
the Pipeline to the RecipientListAggregator. Currently, the properties are lost
by the HTTP BC provider transformer. If I use a JMS BC provider with an IN-OUT
MEP as the transformer, the properties are also lost.
If I alter the scenario to use CXF-SE as the transformer, the properties are
also lost. In this particular case, the problem seems to me to be a CXF-SE
limitation. The old TransformComponentSupport.java class offered convenient
copyProperties and copyAttachments booleans to control this behavior. Should
CXF-SE offer something similar in an xbean-declarative fashion? Should I open a
JIRA for CXF-SE to add declarative support for both copying properties and
copying attachments? Nevertheless, this proposed Pipeline patch would work
around this CXF-SE limitation, albeit adding needless store-related overhead.
Now that I think about it, does it make sense to add another boolean property
to the Pipeline that also supports copying attachments? Since they are already
sitting in the store just like the properties, this should also be
straightforward to implement.
Let me know your thoughts.
- Ron
was (Author: rgavlin):
Just to be clear, one of my representative use cases is as follows:
EIP StaticRecipientList -> Saxon -> Pipeline (transformer = HTTP BC provider)
-> RecipientListAggregator
->
RecipientListAggregator -> Saxon
Here, I need the properties added by the StaticRecipientList to pass through
the Pipeline to the RecipientListAggregator. Currently, the properties are lost
by the HTTP BC provider transformer. If I use a JMS BC provider with an IN-OUT
MEP as the transformer, the properties are also lost.
If I alter the scenario to use CXF-SE as the transformer, the properties are
also lost. In this particular case, the problem seems to me to be a CXF-SE
limitation. The old TransformComponentSupport.java class offered convenient
copyProperties and copyAttachments booleans to control this behavior. Should
CXF-SE offer something similar in an xbean-declarative fashion? Should I open a
JIRA for CXF-SE to add declarative support for both copying properties and
copying attachments? Nevertheless, this proposed Pipeline patch would work
around this CXF-SE limitation, albeit adding needless store-related overhead.
Now that I think about it, does it make sense to add another boolean property
to the Pipeline that also supports copying attachments? Since they are already
sitting in the store just like the properties, this should also be
straightforward to implement.
Let me know your thoughts.
- Ron
> EIP Pipeline should propagate message properties across asynchronous exchanges
> ------------------------------------------------------------------------------
>
> Key: SM-1238
> URL: https://issues.apache.org/activemq/browse/SM-1238
> Project: ServiceMix
> Issue Type: New Feature
> Components: servicemix-eip
> Affects Versions: 3.2.1
> Reporter: Ron Gavlin
> Attachments: Pipeline.java.patch
>
>
> EIP Pipeline output properties should be the same as input properties except
> where modified by the transform in asynchronous exchanges.
> Also, StreamSource faults should be localized before returning to the
> exchange.
> I hope to submit a patch for this issue shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
