Marc Giger created CAMEL-13851:
----------------------------------
Summary: camel-xj component contribution
Key: CAMEL-13851
URL: https://issues.apache.org/jira/browse/CAMEL-13851
Project: Camel
Issue Type: New Feature
Affects Versions: 3.0.0.M4, 2.24.1
Reporter: Marc Giger
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
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
