anchor.diff:  To deliver content over the wire we must ensure that the body of the
   message that is being delivered adheres to the JMS Message
   Specification. Therefore, all that are produced must either be
  -primitives or their counter objects (such as Integer, Long, Character).
  -The types, String, CharSequence, Date, BigDecimal and BigInteger are all
  -converted to their toString() representation. All other types are
  +primitives or their counter objects (such as `Integer`, `Long`, `Character`).
  +The types, `String`, `CharSequence`, `Date`, `BigDecimal` and `BigInteger` are all
  +converted to their `toString()` representation. All other types are
   dropped.
   
   [[SJMS-Clustering]]
   Clustering
   ++++++++++
   
  -When using InOut with SJMS in a clustered environment you must either
  +When using _InOut_ with SJMS in a clustered environment you must either
   use TemporaryQueue destinations or use a unique named reply to
   destination per InOut producer endpoint. Message correlation is handled
   by the endpoint, not with message selectors at the broker. The InOut
   Producer Endpoint uses Java Concurrency Exchangers cached by the Message
  -JMSCorrelationID. This provides a nice performance increase while
  +`JMSCorrelationID`. This provides a nice performance increase while
   reducing the overhead on the broker since all the messages are consumed
   from the destination in the order they are produced by the interested
   consumer.
   
  -Currently the only correlation strategy is to use the JMSCorrelationId.
  -The InOut Consumer uses this strategy as well ensuring that all
  -responses messages to the included JMSReplyTo destination also have the
  -JMSCorrelationId copied from the request as well.
  +Currently the only correlation strategy is to use the `JMSCorrelationId`.
  +The _InOut_ Consumer uses this strategy as well ensuring that all
  +responses messages to the included `JMSReplyTo` destination also have the
  +`JMSCorrelationId` copied from the request as well.
   
   [[SJMS-TransactionSupporttransactions]]
   Transaction Support [[SJMS-transactions]]
  
positive.code: InOut Producer
  ++++++++++++++
  
  To enable InOut behavior append the `exchangePattern` attribute to the
  URI. By default it will use a dedicated TemporaryQueue for each
  consumer.
  
  
negative.code: the Camel JMS Component. This plugable strategy ensures that messages
  sent over the wire conform to the JMS Message spec.
  
  For the `exchange.in.header` the following rules apply for the header
  keys:
  
  * Keys starting with `JMS` or `JMSX` are reserved.
  * `exchange.in.headers` keys must be literals and all be valid Java
  identifiers (do not use dots in the key name).
  * Camel replaces dots & hyphens and the reverse when when consuming JMS
  messages:
  
  ** is replaced by _DOT_ and the reverse replacement when Camel consumes
  the message.
  ** is replaced by _HYPHEN_ and the reverse replacement when Camel
  consumes the message. +
  See also the option `jmsKeyFormatStrategy`, which allows use of your own
  custom strategy for formatting keys.
  
  For the `exchange.in.header`, the following rules apply for the header
  values:
  
  [[SJMS-MessageContent]]
  