anchor.diff:  =====Boundary events and multi-instance
   
   
  -          Since a multi-instance is a regular activity, it is possible to define a 
  +          Since a multi-instance is a regular activity, it is possible to define a
             <<bpmnBoundaryEvent,boundary event>> on its boundary.
             In case of an interrupting boundary event, when the event is caught, *all instances*
             that are still active will be destroyed. Take for example following multi-instance subprocess:
  -          
  +
             Here, all instances of the subprocess will be destroyed when the timer fires, regardless
             of how many instances there are or which inner activities are currently not yet completed.
  -        
  +
   
   [[bpmnCompensationHandlers]]
   
  
positive.code: 
            The Camel task is implemented as a dedicated <<bpmnJavaServiceTask,Service Task>>
            and is defined by setting _'camel'_ for the _type_ of the service task.
            
  ++++++++++++++++++++++++++++++++++++++
  <programlisting format="linespecific">
  &lt;serviceTask id="sendCamel" <emphasis role="bold">activiti:type="camel"</emphasis>&gt;         
            </programlisting>
  ++++++++++++++++++++++++++++++++++++++
  
  
          
  
  
            The process definition itself needs nothing else then the camel type definition on a service task.
            The integration logic is all delegated to the Camel container. By default the Activiti Engine looks for a camelContext bean in the Spring container.
            The camelContext bean defines the Camel routes that will be loaded by the Camel container. In the following example the routes are loaded from a specific Java package,
            but you can also define routes directly in the Spring configuration itself.
           
  ----
  
  <camelContext id="camelContext" xmlns="http://camel.apache.org/schema/spring">
  
negative.code: ====Fail Retry
  
  
  		Activiti, in its default configuration, reruns a job 3 times in case of any exception in execution of a job. This holds also for asynchronous task jobs.
  		In some cases more flexibility is required. There are two parameters to be configured:
  
  *
  				Number of retries
  *
  				Delay between retries
  		These parameters can be configured by +activiti:failedJobRetryTimeCycle+ element. Here is a sample usage:
  
  
  ----
  
  <serviceTask id="failingServiceTask" activiti:async="true" activiti:class="org.activiti.engine.test.jobexecutor.RetryFailingDelegate">
  