diff --git a/src/reference/docbook/beans-customizing.xml b/src/reference/docbook/beans-customizing.xml
index acca5514a7..9e5c4284b9 100644
--- a/src/reference/docbook/beans-customizing.xml
+++ b/src/reference/docbook/beans-customizing.xml
@@ -13,18 +13,25 @@
   <section xml:id="beans-factory-lifecycle">
     <title>Lifecycle callbacks</title>
 
-    <!-- MLP Beverly to review: Old Text: The Spring Framework provides several callback interfaces to
-    change the behavior of your bean in the container; they include -->
-
     <para>To interact with the container's management of the bean lifecycle, you
       can implement the Spring <interfacename>InitializingBean</interfacename>
       and <interfacename>DisposableBean</interfacename> interfaces. The
       container calls <methodname>afterPropertiesSet()</methodname> for the
       former and <methodname>destroy()</methodname> for the latter to allow the
       bean to perform certain actions upon initialization and destruction of
-      your beans. You can also achieve the same integration with the container
-      without coupling your classes to Spring interfaces through the use of
-      init-method and destroy method object definition metadata.</para>
+      your beans.</para>
+
+      <tip>
+          <para>The JSR-250 <interfacename>@PostConstruct</interfacename> and
+          <interfacename>@PreDestroy</interfacename> annotations are generally
+          considered best practice for receiving lifecycle callbacks in a modern
+          Spring application. Using these annotations means that your beans are not
+          coupled to Spring specific interfaces. For details see
+          <xref linkend="beans-postconstruct-and-predestroy-annotations"/>.</para>
+          <para>If you don't want to use the JSR-250 annotations but you are still
+          looking to remove coupling consider the use of init-method and destroy-method
+          object definition metadata.</para>
+      </tip>
 
     <para>Internally, the Spring Framework uses
       <interfacename>BeanPostProcessor</interfacename> implementations to
@@ -57,7 +64,9 @@
 
       <para>It is recommended that you do not use the
         <interfacename>InitializingBean</interfacename> interface because it
-        unnecessarily couples the code to Spring. Alternatively, specify a POJO
+        unnecessarily couples the code to Spring. Alternatively, use the
+        <link linkend="beans-postconstruct-and-predestroy-annotations">
+        <interfacename>@PostConstruct</interfacename> annotation</link> or specify a POJO
         initialization method. In the case of XML-based configuration metadata,
         you use the <literal>init-method</literal> attribute to specify the name
         of the method that has a void no-argument signature. For example, the
@@ -99,7 +108,9 @@
 
       <para>It is recommended that you do not use the
         <interfacename>DisposableBean</interfacename> callback interface because
-        it unnecessarily couples the code to Spring. Alternatively, specify a
+        it unnecessarily couples the code to Spring. Alternatively, use the
+        <link linkend="beans-postconstruct-and-predestroy-annotations">
+        <interfacename>@PreDestroy</interfacename> annotation</link> or specify a
         generic method that is supported by bean definitions. With XML-based
         configuration metadata, you use the <literal>destroy-method</literal>
         attribute on the <literal>&lt;bean/&gt;</literal>. For example, the