JAXB by default escapes characters inside a string in the Java model when it converts the Java model to XML. This creates issues if you have CDATA present in the string. You will have even the CDATA tags escaped [i.e <![CDATA[< ], which makes it difficult for the consumer of the final XML for processing. So, to avoid this and to handle CDATA in JAXB the way you want, there are 3 approaches :
- Using XMLSerializer and OutputFormat : Usage of this can be found in here. In the OutputFormat, one can specify the elements to be treated as CDATA. But both these classes XMLSerializer and OutputFormat - have been deprecated since Xerces 2.9.0. Latest Xerces version is 2.11.0. Following is what the Xerces documentation says : This class was deprecated in Xerces 2.9.0. It is recommended that new applications use the DOM Level 3 LSSerializer or JAXP's Transformation API for XML (TrAX) for serializing XML. See the Xerces documentation for more information. Ref https://xerces.apache.org/xerces2-j/javadocs/other/org/apache/xml/serialize/XMLSerializer.html https://xerces.apache.org/xerces2-j/javadocs/other/org/apache/xml/serialize/OutputFormat.html
- Using XMLAdapter and Character Escape Handler : In this approach, one needs to
- Specify Adapter class in the bindings.xjb for String element to be handled as CDATA. You can find how to specify it here. In the adapter class, in the marshall method one needs to add CDATA tag to the argument string.
- During marshalling of the javamodel by JAXB, one needs to specify CharacterEscapeHandler which can handle CDATA element without escaping. You can find usage here. Any other special handling like escaping in certain cases, also need to be handled. This is a nightmare to maintain.
- Using JAVAX XML Transformer APIs : You can find the usage of this approach here. In this case, Javamodel from JAXB would be marshalled into a DOM document(w3 doc). Then, it would be transformed into XML string the way we want by JAVAX Transformer. In the Transformer, we can specify the list of elements to be handled as CDATA.
I would recommend using the third approach since it is configurable, easy to maintain and part of standard Java package.