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"]
@@ -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,7 +2133,7 @@ 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.
@@ -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.
@@ -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.
 
@@ -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