diff --git a/docs/src/reference/docbook/content-enrichment.xml b/docs/src/reference/docbook/content-enrichment.xml
index b9b363327e..9223183b64 100644
--- a/docs/src/reference/docbook/content-enrichment.xml
+++ b/docs/src/reference/docbook/content-enrichment.xml
@@ -6,8 +6,8 @@
   <section id="content-enricher-introduction">
     <title>Introduction</title>
    <para>
-   Some time you may have a requirement to enhance a request with more information then it was 
-   provided by the target system. <link href="http://www.eaipatterns.com/DataEnricher.html">Content Enricher</link> pattern 
+   At times you may have a requirement to enhance a request with more information than was 
+   provided by the target system. The <link href="http://www.eaipatterns.com/DataEnricher.html">Content Enricher</link> pattern 
    describes various scenarios as well as the component (Enricher), which allows you to address such requirements.
    </para>
   </section>
@@ -17,8 +17,9 @@
    
     <para>
     If you only need to add headers to a Message, and they are not dynamically determined by the Message content,
-    then referencing a custom implementation of the Transformer may be an overkill. For that reason, 
-    Spring Integration provides the <emphasis>Header Enricher</emphasis> which is exposed via <code>&lt;header-enricher&gt;</code> element.   
+    then referencing a custom implementation of a Transformer may be overkill. For that reason, 
+    Spring Integration provides support for the <emphasis>Header Enricher</emphasis> pattern. It is exposed via
+    the <code>&lt;header-enricher&gt;</code> element.   
     
 	    <programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
      <int:header name="foo" value="123"/>
@@ -27,7 +28,7 @@
 
     </para>
     <para>
-    <emphasis>Header Enricher</emphasis> also provides helpful sub-elements to set well known header names.
+    The <emphasis>Header Enricher</emphasis> also provides helpful sub-elements to set well-known header names.
     <programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
 		<int:error-channel ref="applicationErrorChannel"/>
 		<int:reply-channel ref="quoteReplyChannel"/>
@@ -36,52 +37,60 @@
 		<int:header name="bar" ref="someBean"/>
 </int:header-enricher>]]></programlisting>
 	
-	In the above configuration you can clearly see that for well known headers such as <code>errorChannel</code>, 
-	<code>correlationId</code>, <code>priority</code>, <code>replyChannel</code>etc., instead of using generic <emphasis>&lt;header&gt;</emphasis> 
-	sub-element where you would have to provide both header 'name' and 'value', you can use convenient sub-elements 
-	allowing you to set those values directly.
+	In the above configuration you can clearly see that for well-known headers such as <code>errorChannel</code>, 
+	<code>correlationId</code>, <code>priority</code>, <code>replyChannel</code>etc., instead of using generic
+    <emphasis>&lt;header&gt;</emphasis> sub-elements where you would have to provide both header 'name' and 'value',
+    you can use convenient sub-elements to set those values directly.
     </para>
+
+    <para>
+    	<emphasis>POJO Support</emphasis>
+    </para>
+    <para>
+      Often a header value cannot be defined statically and has to be determined dynamically based on some content in the Message. That is why 
+      <emphasis>Header Enricher</emphasis> allows you to also specify a bean 'ref' and 'method' that will calculate the 
+      header value. Let's look at the following configuration:
+
+      <programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
+    <int:header name="foo" method="computeValue" ref="myBean"/>
+</int:header-enricher>
+
+<bean id="myBean" class="foo.bar.MyBean"/>]]></programlisting>
+
+<programlisting language="java"><![CDATA[public class MyBean {
+    public String computeValue(String payload){
+        return payload.toUpperCase() + "_US";
+    }
+
+}]]></programlisting>
+    </para>
+
     <para>
     	<emphasis>SpEL Support</emphasis>
     </para>
     <para>
-    In Spring Integration 2.0 we are introducing convenience of 
+    In Spring Integration 2.0 we have introduced the convenience of the
     <link href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html">Spring Expression Language (SpEL)</link>
-     to help configure many different components. <emphasis>Header Enricher</emphasis> is one of them. 
-	A lot of times, header value cannot be defined statically and has to be computed dynamically. That is why 
-	<emphasis>Header Enricher</emphasis> allows you to also specify bean 'ref' and 'method' that will calculate the 
-	header value. Let's look at the following configuration:
-		
-	<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
-		<int:header name="foo" method="computeValue" ref="myBean"/>
-</int:header-enricher>
-	
-<bean id="myBean" class="foo.bar.MyBean"/>]]></programlisting>
+     to help configure many different components. The <emphasis>Header Enricher</emphasis> is one of them. 
 
-<programlisting language="java"><![CDATA[public class MyBean{
-	public String computeValue(String payload){
-		return payload.toUpperCase() + "_US";
-	}
-}]]></programlisting>
+	Looking again at the POJO example above, you can see that the computation logic to determine the header value is actually pretty simple. 
+	A natural question would be: "is there a simpler way to accomplish this?". That is where SpEL shows its true power.
 
-	As you can see that the computation logic to determine the header value is actually pretty simple and the 
-	natural question would be is there a simpler way to accomplish this? And that is where SpEL shows its true power.
-	
 	<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
 	<int:header name="foo" expression="payload.toUpperCase() + '_US'"/>
 </int:header-enricher>]]></programlisting>
 
-	As you can see, with SpEL for simple cases like above we no longer have to provide a separate class and configure 
-	it in the application context. All we need is to use <emphasis>expression</emphasis> attribute and provide a valid 
-	SpEL expression. You can also see that 'payload' and 'headers' are bound as variables to the SpEL Evaluation Context 
+	As you can see, by using SpEL for such simple cases, we no longer have to provide a separate class and configure 
+	it in the application context. All we need is the <emphasis>expression</emphasis> attribute configured with a valid 
+	SpEL expression. The 'payload' and 'headers' variables are bound to the SpEL Evaluation Context, 
 	giving you full access to the incoming Message.
-    </para>		
+    </para>
     <para>
     	<emphasis>Adapter specific Header Enrichers</emphasis>
     </para>
     <para>
-    As you go through the manual you will see that as an added convenience 
-    Spring Integration provides adapter specific Header Enrichers (e.g., MAIL, XMPP, etc.)
+    As you go through the manual, you will see that as an added convenience,
+    Spring Integration also provides adapter specific Header Enrichers (e.g., MAIL, XMPP, etc.)
  	</para>
   </section>
 
diff --git a/docs/src/reference/docbook/control-bus.xml b/docs/src/reference/docbook/control-bus.xml
index a59fd2fea8..4aecefdb34 100644
--- a/docs/src/reference/docbook/control-bus.xml
+++ b/docs/src/reference/docbook/control-bus.xml
@@ -25,21 +25,24 @@
   <para>The Control Bus executes messages on the input channel as Spring
   Expression Language expressions. It takes a message, compiles the body to an
   expression, adds some context, and then executes it. The default context
-  just exposes all the beans in the application context by name with the usual
-  SpEL prefix for beans (@). So to execute a method on a Spring Bean a client
-  would send a message to the operation channel:</para>
+  supports any method that has been annotated with @ManagedAttribute or @ManagedOperation.
+  It also supports the methods on Spring's Lifecycle interface, and it supports methods
+  that are used to configure several of Spring's TaskExecutor and TaskScheduler implementations.
+  The simplest way to ensure that your own methods are available to the Control Bus is to
+  use the @ManagedAttribute and/or @ManagedOperation annotations. Since those are also used
+  for exposing methods to a JMX MBean registry, it's a convenient by-product (often the same
+  types of operations you want to expose to the Control Bus would be reasonable for exposing
+  via JMS). Resolution of any particular instance within the application context is achieved
+  in the typical SpEL syntax. Simply provide the bean name with the SpEL prefix for beans (@).
+  For example, to execute a method on a Spring Bean a client
+  could send a message to the operation channel as follows:</para>
 
   <programlisting>Message operation = MessageBuilder.withPayload("@myServiceBean.shutdown()");
 operationChannel.send(operation)</programlisting>
 
   <para>The root of the context for the expression is the
-  <classname>Message</classname> itself, so you also have access to the body
-  and headers, the same as all the other expressions in Spring Integration
-  endpoints.</para>
+  <classname>Message</classname> itself, so you also have access to the 'payload'
+  and 'headers' as variables within your expression. This is consistent with all the other expression
+  support in Spring Integration endpoints.</para>
 
-  <para>The execution context for the expressions can be customized by
-  providing a <classname>BeanResolver</classname> instance:</para>
-
-  <programlisting language="xml">&lt;control-bus input-channel="operationChannel" bean-resolver="beanResolver"/&gt;
-&lt;beans:bean class="com.mycompany.MyCustomBeanResolver"/&gt;</programlisting>
 </section>