Details
-
New Feature
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
2.24.1, 3.0.0.M4
-
None
-
None
-
Unknown
Description
Hi,
For a customer of mine i've setup an ESB infrastructure (JBoss Fuse) and implement camel routes for some time now. Until now i've used camel-xmljson that was nicely expressed "not so nice". It was always a pain to get the desired output and needed most of the time some hacks. Lately we had some performance issues with "larger" messages and the culprit was again the xmljson lib because of its excessive regex use. Apart from that camel-xmljson was removed from camel (correctly). So, time for a new component for direct xml <-> json conversion.
Thanks goes to "Berner Fachhochschule" to allow me to work and contribute the component.
On a high level the component works as follows:
xml -> xslt -> json and json -> xslt -> xml
This allows to transform the input document directly in the desired target structure without the need of an intermediary format.
More in detail:
xml -> xslt -> XmlJsonStreamWriter -> json
The XmlJsonStreamWriter is a custom impl. of javax.xml.stream.XMLStreamWriter that acts as a StAX -> JsonEvent bridge and uses internally com.fasterxml.jackson.core.JsonGenerator as json writer.
In the other direction:
json -> JsonXmlStreamReader -> xslt -> xml
Here the JsonXmlStreamReader is a custom impl. of avax.xml.stream.XMLStreamReader that acts as a JsonEvent -> StAX bridge and uses internally com.fasterxml.jackson.core.JsonParser as json reader.
The json -> xml conversion is fully event driven. That means that just the current token is held in memory. In the other direction, xml -> json, a internal tree needs to be built and therefore the complete json document is held in memory. Actually I can even see a possibility to stream it under some circumstandes.
The current implementation can be found in:
https://github.com/kayuma/camel/tree/camel-xj-component
The question is now if the camel community is interested in this contribution?
Open Issues:
- Some of the classes are copies from the xslt component because of minor but important differences that are required to get XJ to work. Maybe we should refactor the xslt component so that it may be extended? Advice needed.
- Documentation
And in the end it would be very nice, if the contribution is accepted, if it could be backported and integrated into camel 2.x
Thanks,
Marc
Attachments
Issue Links
- links to
