Oliver Jelinski created CAMEL-6794:
--------------------------------------
Summary: XSLT Aggregation Strategies?
Key: CAMEL-6794
URL: https://issues.apache.org/jira/browse/CAMEL-6794
Project: Camel
Issue Type: New Feature
Components: camel-core
Affects Versions: 2.12.1
Reporter: Oliver Jelinski
Hi Camel team,
my wish for a new feature already came up a long time ago, in CAMEL-2820, but
this was closed, because the requester didn't give enough information on this.
So I try it again, with a bit more info...
I am processing xml via camel a lot and I'm working a lot with the xslt
component for transformations. This works fine and I think it is solved by you
in a very elegant way.
But very often I also need to split my xml for processing of the
maxOccurs="unbounded"-Elements one-by-one. This also works fine, but when it
comes to aggregating the elements again, I need to write a
java-AggregationStrategy for that.
Basically, what the java AggregationStrategy does, would be also achievable
with XSLT: having an old exchange (that is null for the first aggregation) and
a new exchange that are however aggregated to a new object that has the same
type as the body of the old exchange.
In XSLT you can transform two (or more) files into one new file, So it would be
totally possible to process one xml-file of namespace x with root element x:a
and another xml-file with namespace y with root element y:b to a target file
which also has the root-element x:a. This could be repeated n times and would
result in an element x:a. -- basically the same behaviour as the java
AggregationStrategies.
So my wish would be to have something like
<split strategyRef="xslt:MyTransformation.xslt" >
...
</split>
If I had that, I would save a lot of marshal/unmarshal operations. I would be
glad, if you took this into consideration.
Best regards,
Oliver
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira