Fix trivial errors in data-access and core-aop in docs

Fix some syntax errors and typos

* Fix syntax error in core-aop docs which caused incorrect document
generation
* Surround @Pointcut values with quotation marks
* Replace 'I' with 'you' in the 'In the XML style I can declare the
first two pointcuts' sentence
* Fix compileror typo
* Remove redundant parenthesis
* Remove redundant commas
* Add 'can' to the 'You configure additional aspects in similar fashion'
sentence
* Replace 'You can annotation any method' with 'You can annotate any
method'
* Add space to 'non-recoverablepersistence'
* Replace 'we shows' with 'we show'
* Fix 'java.utils.Map' typo
* Add space to 'byusing'
* Add space to '`Lifecycle`by'
* Replace 'You cN' with 'You can'
* Replace 'encourag' with 'encourage'

src/docs/asciidoc/core/core-aop.adoc

@@ -1328,7 +1328,8 @@ If the first parameter is of the `JoinPoint`, `ProceedingJoinPoint`, or
 of the `argNames` attribute. For example, if you modify the preceding advice to receive
 the join point object, the `argNames` attribute need not include it:
 +
-====[source,java,indent=0]
+====
+[source,java,indent=0]
 [subs="verbatim,quotes"]
 ----
 	@Before(value="com.xyz.lib.Pointcuts.anyPublicMethod() && target(bean) && @annotation(auditable)",
@@ -1751,7 +1752,7 @@ Assume that you have a `SystemArchitecture` aspect as described in <<aop-common-
 Then declaring a pointcut inside an aspect is very similar to declaring a top-level pointcut,
 as the following example shows:
 
-===
+====
 [source,xml,indent=0]
 [subs="verbatim"]
 ----
@@ -2564,18 +2565,18 @@ something like the following:
 [source,java,indent=0]
 [subs="verbatim"]
 ----
-	@Pointcut(execution(* get*()))
+	@Pointcut("execution(* get*())")
 	public void propertyAccess() {}
 
-	@Pointcut(execution(org.xyz.Account+ *(..))
+	@Pointcut("execution(org.xyz.Account+ *(..))")
 	public void operationReturningAnAccount() {}
 
-	@Pointcut(propertyAccess() && operationReturningAnAccount())
+	@Pointcut("propertyAccess() && operationReturningAnAccount()")
 	public void accountPropertyAccess() {}
 ----
 ====
 
-In the XML style I can declare the first two pointcuts:
+In the XML style you can declare the first two pointcuts:
 
 [source,xml,indent=0]
 [subs="verbatim"]
@@ -2862,7 +2863,7 @@ See the {api-spring-framework}/aop/aspectj/annotation/AspectJProxyFactory.html[J
 == Using AspectJ with Spring Applications
 
 Everything we have covered so far in this chapter is pure Spring AOP. In this section,
-we look at how you can use the AspectJ compileror weaver instead of or in
+we look at how you can use the AspectJ compiler or weaver instead of or in
 addition to Spring AOP if your needs go beyond the facilities offered by Spring AOP
 alone.
 
@@ -2910,7 +2911,7 @@ following example shows:
 When used as a marker interface in this way, Spring configures new instances of the
 annotated type (`Account`, in this case) by using a bean definition (typically
 prototype-scoped) with the same name as the fully-qualified type name
-()`com.xyz.myapp.domain.Account`). Since the default name for a bean is the
+(`com.xyz.myapp.domain.Account`). Since the default name for a bean is the
 fully-qualified name of its type, a convenient way to declare the prototype definition
 is to omit the `id` attribute, as the following example shows:
 

src/docs/asciidoc/data-access.adoc

@@ -1719,7 +1719,7 @@ transactional advice on the way out, you can swap the value of the profiling
 aspect bean's `order` property so that it is higher than the transactional advice's
 order value.
 
-You configure additional aspects in similar fashion.
+You can configure additional aspects in similar fashion.
 
 
 
@@ -1765,7 +1765,7 @@ The `@Transactional` annotation on a class specifies the default transaction sem
 for the execution of any public method in the class.
 
 The `@Transactional` annotation on a method within the class overrides the default
-transaction semantics given by the class annotation (if present). You can annotation any method,
+transaction semantics given by the class annotation (if present). You can annotate any method,
 regardless of visibility.
 
 To weave your applications with the `AnnotationTransactionAspect`, you must either build
@@ -2133,14 +2133,14 @@ specific to each technology.
 [[dao-exceptions]]
 === Consistent Exception Hierarchy
 
-Spring provides a convenient translation from technology-specific exceptions,, such as
+Spring provides a convenient translation from technology-specific exceptions, such as
 `SQLException` to its own exception class hierarchy, which has `DataAccessException` as
 the root exception. These exceptions wrap the original exception so that there is never any
 risk that you might lose any information about what might have gone wrong.
 
 In addition to JDBC exceptions, Spring can also wrap JPA- and Hibernate-specific exceptions,
 converting them to a set of focused runtime exceptions.
-This lets you handle most non-recoverablepersistence exceptions
+This lets you handle most non-recoverable persistence exceptions
 in only the appropriate layers, without having annoying boilerplate
 catch-and-throw blocks and exception declarations in your DAOs. (You can still trap
 and handle exceptions anywhere you need to though.) As mentioned above, JDBC
@@ -2190,7 +2190,7 @@ Any DAO or repository implementation needs access to a persistence resource,
 depending on the persistence technology used. For example, a JDBC-based repository
 needs access to a JDBC `DataSource`, and a JPA-based repository needs access to an
 `EntityManager`. The easiest way to accomplish this is to have this resource dependency
-injected by using one of the `@Autowired,`, `@Inject`, `@Resource` or `@PersistenceContext`
+injected by using one of the `@Autowired`, `@Inject`, `@Resource` or `@PersistenceContext`
 annotations. The following example works for a JPA repository:
 
 ====
@@ -3643,7 +3643,7 @@ layer's initialization method. For this example, the initializing method is the
 you can create a new instance and set the table name by using the `withTableName` method.
 Configuration methods for this class follow the `fluid` style that returns the instance
 of the `SimpleJdbcInsert`, which lets you chain all configuration methods. The following
-example uses only one configuration method (we shows examples of multiple methods later):
+example uses only one configuration method (we show examples of multiple methods later):
 
 ====
 [source,java,indent=0]
@@ -3672,7 +3672,7 @@ example uses only one configuration method (we shows examples of multiple method
 ----
 ====
 
-The `execute` method used here takes a plain `java.utils.Map` as its only parameter. The
+The `execute` method used here takes a plain `java.util.Map` as its only parameter. The
 important thing to note here is that the keys used for the `Map` must match the column
 names of the table, as defined in the database. This is because we read the metadata
 to construct the actual insert statement.
@@ -4401,7 +4401,7 @@ example, the `StoredProcedure` class is an inner class. However, if you need to
 parameters, but an output parameter is declared as a date type by using the
 `SqlOutParameter` class. The `execute()` method runs the procedure and extracts the
 returned date from the results `Map`. The results `Map` has an entry for each declared
-output parameter (in this case, only one) byusing the parameter name as the key.
+output parameter (in this case, only one) by using the parameter name as the key.
 The following listing shows our custom StoredProcedure class:
 
 ====
@@ -5029,7 +5029,7 @@ inadvertently attempts to recreate additional instances of the same database. Th
 happen quite easily if an XML configuration file or `@Configuration` class is responsible
 for creating an embedded database and the corresponding configuration is then reused
 across multiple testing scenarios within the same test suite (that is, within the same JVM
-process) –- for example, integration tests against embedded databases whose
+process) -- for example, integration tests against embedded databases whose
 `ApplicationContext` configuration differs only with regard to which bean definition
 profiles are active.
 
@@ -5205,7 +5205,7 @@ Some suggestions for how to implement this include:
 * Have your cache or a separate component that initializes the cache implement
   `Lifecycle` or `SmartLifecycle`. When the application context starts, you can
   automatically start a `SmartLifecycle` by setting its `autoStartup` flag, and you can
-  manually start a `Lifecycle`by calling `ConfigurableApplicationContext.start()`
+  manually start a `Lifecycle` by calling `ConfigurableApplicationContext.start()`
   on the enclosing context.
 * Use a Spring `ApplicationEvent` or similar custom observer mechanism to trigger the
   cache initialization. `ContextRefreshedEvent` is always published by the context when
@@ -5593,7 +5593,7 @@ focus on adding business logic, which is the real value of your application.
 NOTE: Before you continue, we are strongly encourage you to read <<transaction-declarative>>
 if you have not already done so.
 
-You cN annotate the service layer with `@Transactional` annotations and instruct the
+You can annotate the service layer with `@Transactional` annotations and instruct the
 Spring container to find these annotations and provide transactional semantics for
 these annotated methods. The following example shows how to do so:
 
@@ -6355,7 +6355,7 @@ a non-invasiveness perspective and can feel more natural to JPA developers.
 [[orm-jpa-tx]]
 ==== Spring-driven JPA transactions
 
-NOTE: We strongly encourag you to read <<transaction-declarative>>, if you have not already done
+NOTE: We strongly encourage you to read <<transaction-declarative>>, if you have not already done
 so, to get more detailed coverage of Spring's declarative transaction support.
 
 The recommended strategy for JPA is local transactions through JPA's native transaction
@@ -6635,7 +6635,7 @@ wraps a different XML representation, as the following table indicates:
 | `java.io.File`, `java.io.InputStream`, or `java.io.Reader`
 |===
 
-Even though there are two separate marshalling interfaces ( `Marshaller` and
+Even though there are two separate marshalling interfaces (`Marshaller` and
 `Unmarshaller`), all implementations in Spring-WS implement both in one class.
 This means that you can wire up one marshaller class and refer to it both as a
 marshaller and as an unmarshaller in your `applicationContext.xml`.