Once upon a time, in a galaxy far away, the W3C defined XML 1.0. If you read the spec for XML 1.0, you will find, perhaps to your astonishment, that some Unicode characters were banished, altogether, from XML. Not relegated to entities, not prohibited in tag names. Forbidden. Altogether. I am not aware of the logic of this decision, except that I have a vague sense that the message was that control characters are obsolete.
Some XML processors ignore this aspect of the spec. Some don't. By default, CXF ends up using one that is picky. It has a lot of other attractive characteristics ... Meanwhile, the whole collection of JAX specs, not to mention all sorts of other specifications, were written on the apparent assumption that a Java String (or any other vector of Unicode characters) could be parcel-posted across the known universe in an xsd:string. Sadly, it is not so. It would have been good if these specs had offered some scheme for packaging up these control characters, but they did not. I'm not enough of a JAXB expert to tell you if there's a snail(@) that will instruct JAXB to send some singular String property as a base64-encoded item. I will tell you that sending multiple MBs of data in the inline XML is probably not a best practice, and attachments were invented as a better solution. Attachments aren't XML if you don't make them XML, and thus you don't hit this situation. In an Aegis mapping xml file, you should be able to ask for a property to be forced to the xsd:base64 type.
