anchor.diff:  *Since Camel 2.14.1*
   
   The JAXB marshaller requires that the message body is JAXB compatible,
  -eg its a JAXBElement, eg a java instance that has JAXB annotations, or
  -extend JAXBElement. There can be situations where the message body is
  -already in XML, eg from a String type. There is a new
  -option `mustBeJAXBElement` you can set to false, to relax this check, so
  -the JAXB marshaller only attempts to marshal JAXBElements
  -(javax.xml.bind.JAXBIntrospector#isElement returns true). And in those
  -situations the marshaller fallbacks to marshal the message body as-is.
  +e.g it is a `JAXBElement`, a java instance that has JAXB annotations, or
  +extends `JAXBElement`. There can be situations where the message body is
  +already in XML, e.g from a `String` type.
  +
  +`JaxbDataFormat` has an option named `mustBeJAXBElement` which you can set to `false` to relax this check and
  +have the JAXB marshaller only attempt marshalling on `JAXBElement` (`javax.xml.bind.JAXBIntrospector#isElement` returns `true`).
  +In those situations the marshaller will fallback to marshal the message body as-is.
   
   == Dependencies
   
  
positive.code: -------------------------------------------------------------------------
  
  Camel will create and pool the underling `SchemaFactory` instances on
  the fly, because the `SchemaFactory` shipped with the JDK is not thread
  safe. +
   However, if you have a `SchemaFactory` implementation which is thread
  safe, you can configure the JAXB data format to use this one:
  
  [source,java]
  --------------------------------------------------------
  
negative.code: 
  *Since Camel 2.14*
  
  The `JaxbDataFormat` supports to specify the `SchemaLocation` when marshalling the XML.
  
  Using the Java DSL, you can configure it in the following way:
  
  