Clarification: Spring AOP pointcuts may match non-public methods

Issue: SPR-15354

Author: jhoeller

src/asciidoc/core-aop.adoc

@@ -405,16 +405,20 @@ proxy (bound to `target`).
 
 [NOTE]
 ====
-Due to the proxy-based nature of Spring's AOP framework, protected methods are by
-definition __not__ intercepted, neither for JDK proxies (where this isn't applicable)
-nor for CGLIB proxies (where this is technically possible but not recommendable for AOP
-purposes). As a consequence, any given pointcut will be matched against __public methods
-only__!
-
-If your interception needs include protected/private methods or even constructors,
-consider the use of Spring-driven <<aop-aj-ltw,native AspectJ weaving>> instead of
-Spring's proxy-based AOP framework. This constitutes a different mode of AOP usage with
-different characteristics, so be sure to make yourself familiar with weaving first
+Due to the proxy-based nature of Spring's AOP framework, calls within the target object
+are by definition __not__ intercepted. For JDK proxies, only public interface method
+calls on the proxy can be intercepted. With CGLIB, public and protected method calls on
+the proxy will be intercepted, and even package-visible methods if necessary. However,
+common interactions through proxies should always be designed through public signatures.
+
+Note that pointcut definitions are generally matched against any intercepted method.
+If a pointcut is strictly meant to be public-only, even in a CGLIB proxy scenario with
+potential non-public interactions through proxies, it needs to be defined accordingly.
+
+If your interception needs include method calls or even constructors within the target
+class, consider the use of Spring-driven <<aop-aj-ltw,native AspectJ weaving>> instead
+of Spring's proxy-based AOP framework. This constitutes a different mode of AOP usage
+with different characteristics, so be sure to make yourself familiar with weaving first
 before making a decision.
 ====
 
@@ -1558,7 +1562,6 @@ advisor, and aspect elements (note these must be declared in that order).
 
 [WARNING]
 ====
-
 The `<aop:config>` style of configuration makes heavy use of Spring's
 <<aop-autoproxy,auto-proxying>> mechanism. This can cause issues (such as advice not
 being woven) if you are already using explicit auto-proxying via the use of

src/asciidoc/core-beans.adoc

@@ -8329,7 +8329,7 @@ synchronously. This means the `publishEvent()` method blocks until all listeners
 finished processing the event. One advantage of this synchronous and single-threaded
 approach is that when a listener receives an event, it operates inside the transaction
 context of the publisher if a transaction context is available. If another strategy for
-event publication becomes necessary, refer to the JavaDoc for Spring's
+event publication becomes necessary, refer to the javadoc for Spring's
 `ApplicationEventMulticaster` interface.
 
 The following example shows the bean definitions used to register and configure each of
@@ -8396,9 +8396,10 @@ follows:
 	}
 ----
 
-As you can see above, the method signature actually _infer_ which even type it listens to. This
-also works for nested generics as long as the actual event resolves the generics parameter you
-would filter on.
+As you can see above, the method signature once again declares the event type it listens to,
+but this time with a flexible name and without implementing a specific listener interface.
+The event type can also be narrowed through generics as long as the actual event type
+resolves your generic parameter in its implementation hierarchy.
 
 If your method should listen to several events or if you want to define it with no
 parameter at all, the event type(s) can also be specified on the annotation itself:
@@ -8408,7 +8409,7 @@ parameter at all, the event type(s) can also be specified on the annotation itse
 ----
 	@EventListener({ContextStartedEvent.class, ContextRefreshedEvent.class})
 	public void handleContextStart() {
-
+		...
 	}
 ----
 
@@ -8658,15 +8659,15 @@ platform's JMX server - all through Spring's standard transaction management and
 and JMX support facilities. Application components can also interact with the
 application server's JCA WorkManager through Spring's `TaskExecutor` abstraction.
 
-Check out the JavaDoc of the
+Check out the javadoc of the
 {api-spring-framework}/jca/context/SpringContextResourceAdapter.html[`SpringContextResourceAdapter`]
 class for the configuration details involved in RAR deployment.
 
 __For a simple deployment of a Spring ApplicationContext as a Java EE RAR file:__ package
 all application classes into a RAR file, which is a standard JAR file with a different
 file extension. Add all required library JARs into the root of the RAR archive. Add a
 "META-INF/ra.xml" deployment descriptor (as shown in ``SpringContextResourceAdapter``s
-JavaDoc) and the corresponding Spring XML bean definition file(s) (typically
+javadoc) and the corresponding Spring XML bean definition file(s) (typically
 "META-INF/applicationContext.xml"), and drop the resulting RAR file into your
 application server's deployment directory.
 

src/asciidoc/core-expressions.adoc

@@ -249,7 +249,7 @@ variables and functions are described in the language reference sections
 <<expressions-ref-variables,Variables>> and <<expressions-ref-functions,Functions>>. The
 `StandardEvaluationContext` is also where you can register custom
 ``ConstructorResolver``s, ``MethodResolver``s, and ``PropertyAccessor``s to extend how SpEL
-evaluates expressions. Please refer to the JavaDoc of these classes for more details.
+evaluates expressions. Please refer to the javadoc of these classes for more details.
 
 
 [[expressions-type-conversion]]