Replace 'e.g.' with 'for example' in documentation and comments

Closes gh-33515

Author: quaff

CONTRIBUTING.md

@@ -86,7 +86,7 @@ multiple edits or corrections of the same logical change. See
 for an overview of streamlining the commit history.
 
 1. Format commit messages using 55 characters for the subject line, 72 characters per line
-for the description, followed by the issue fixed, e.g. `Closes gh-22276`. See the
+for the description, followed by the issue fixed, for example, `Closes gh-22276`. See the
 [Commit Guidelines section of Pro Git](https://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Commit-Guidelines)
 for best practices around commit messages, and use `git log` to see some examples.
 

framework-docs/modules/ROOT/pages/core/aop/ataspectj/introductions.adoc

@@ -9,7 +9,7 @@ You can make an introduction by using the `@DeclareParents` annotation. This ann
 is used to declare that matching types have a new parent (hence the name). For example,
 given an interface named `UsageTracked` and an implementation of that interface named
 `DefaultUsageTracked`, the following aspect declares that all implementors of service
-interfaces also implement the `UsageTracked` interface (e.g. for statistics via JMX):
+interfaces also implement the `UsageTracked` interface (for example, for statistics via JMX):
 
 [tabs]
 ======

framework-docs/modules/ROOT/pages/core/aop/introduction-defn.adoc

@@ -65,7 +65,7 @@ with less potential for errors. For example, you do not need to invoke the `proc
 method on the `JoinPoint` used for around advice, and, hence, you cannot fail to invoke it.
 
 All advice parameters are statically typed so that you work with advice parameters of
-the appropriate type (e.g. the type of the return value from a method execution) rather
+the appropriate type (for example, the type of the return value from a method execution) rather
 than `Object` arrays.
 
 The concept of join points matched by pointcuts is the key to AOP, which distinguishes

framework-docs/modules/ROOT/pages/core/beans/annotation-config.adoc

@@ -20,7 +20,7 @@ can be found in the xref:core/beans/standard-annotations.adoc[relevant section].
 [NOTE]
 ====
 Annotation injection is performed before external property injection. Thus, external
-configuration (e.g. XML-specified bean properties) effectively overrides the annotations
+configuration (for example, XML-specified bean properties) effectively overrides the annotations
 for properties when wired through mixed approaches.
 ====
 

framework-docs/modules/ROOT/pages/core/beans/context-introduction.adoc

@@ -484,7 +484,7 @@ You can register as many event listeners as you wish, but note that, by default,
 This means that the `publishEvent()` method blocks until all listeners have 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, e.g. asynchronous event processing by default,
+If another strategy for event publication becomes necessary, for example, asynchronous event processing by default,
 see the javadoc for Spring's {spring-framework-api}/context/event/ApplicationEventMulticaster.html[`ApplicationEventMulticaster`] interface
 and {spring-framework-api}/context/event/SimpleApplicationEventMulticaster.html[`SimpleApplicationEventMulticaster`] implementation
 for configuration options which can be applied to a custom "applicationEventMulticaster" bean definition.
@@ -864,7 +864,7 @@ Finally, as with classic `ApplicationListener` implementations, the actual multi
 happens via a context-wide `ApplicationEventMulticaster` at runtime. By default, this is a
 `SimpleApplicationEventMulticaster` with synchronous event publication in the caller thread.
 This can be replaced/customized through an "applicationEventMulticaster" bean definition,
-e.g. for processing all events asynchronously and/or for handling listener exceptions:
+for example, for processing all events asynchronously and/or for handling listener exceptions:
 
 [source,java,indent=0,subs="verbatim,quotes"]
 ----

framework-docs/modules/ROOT/pages/core/beans/factory-nature.adoc

@@ -144,7 +144,7 @@ based on the given configuration but no further activity with external bean acce
 Otherwise there is a risk for an initialization deadlock.
 
 For a scenario where expensive post-initialization activity is to be triggered,
-e.g. asynchronous database preparation steps, your bean should either implement
+for example, asynchronous database preparation steps, your bean should either implement
 `SmartInitializingSingleton.afterSingletonsInstantiated()` or rely on the context
 refresh event: implementing `ApplicationListener<ContextRefreshedEvent>` or
 declaring its annotation equivalent `@EventListener(ContextRefreshedEvent.class)`.
@@ -607,7 +607,7 @@ bean creation phase and its subsequent initial publication, they need to be decl
 `volatile` or guarded by a common lock whenever accessed.
 
 Note that concurrent access to such configuration state in singleton bean instances,
-e.g. for controller instances or repository instances, is perfectly thread-safe after
+for example, for controller instances or repository instances, is perfectly thread-safe after
 such safe initial publication from the container side. This includes common singleton
 `FactoryBean` instances which are processed within the general singleton lock as well.
 
@@ -617,7 +617,7 @@ structures (or in `volatile` fields for simple cases) as per common Java guideli
 
 Deeper `Lifecycle` integration as shown above involves runtime-mutable state such as
 a `runnable` field which will have to be declared as `volatile`. While the common
-lifecycle callbacks follow a certain order, e.g. a start callback is guaranteed to
+lifecycle callbacks follow a certain order, for example, a start callback is guaranteed to
 only happen after full initialization and a stop callback only after an initial start,
 there is a special case with the common stop before destroy arrangement: It is strongly
 recommended that the internal state in any such bean also allows for an immediate

framework-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc

@@ -219,7 +219,7 @@ parameter-based injection, as in the preceding example.
 Avoid access to locally defined beans within a `@PostConstruct` method on the same configuration
 class. This effectively leads to a circular reference since non-static `@Bean` methods semantically
 require a fully initialized configuration class instance to be called on. With circular references
-disallowed (e.g. in Spring Boot 2.6+), this may trigger a `BeanCurrentlyInCreationException`.
+disallowed (for example, in Spring Boot 2.6+), this may trigger a `BeanCurrentlyInCreationException`.
 
 Also, be particularly careful with `BeanPostProcessor` and `BeanFactoryPostProcessor` definitions
 through `@Bean`. Those should usually be declared as `static @Bean` methods, not triggering the

framework-docs/modules/ROOT/pages/core/databuffer-codec.adoc

@@ -29,7 +29,7 @@ a `DataBuffer` implementation and that does not involve allocation.
 
 Note that WebFlux applications do not create a `DataBufferFactory` directly but instead
 access it through the `ServerHttpResponse` or the `ClientHttpRequest` on the client side.
-The type of factory depends on the underlying client or server, e.g.
+The type of factory depends on the underlying client or server, for example,
 `NettyDataBufferFactory` for Reactor Netty, `DefaultDataBufferFactory` for others.
 
 
@@ -82,7 +82,7 @@ to use the convenience methods in `DataBufferUtils` that apply release or retain
 
 `DataBufferUtils` offers a number of utility methods to operate on data buffers:
 
-* Join a stream of data buffers into a single buffer possibly with zero copy, e.g. via
+* Join a stream of data buffers into a single buffer possibly with zero copy, for example, via
 composite buffers, if that's supported by the underlying byte buffer API.
 * Turn `InputStream` or NIO `Channel` into `Flux<DataBuffer>`, and vice versa a
 `Publisher<DataBuffer>` into `OutputStream` or NIO `Channel`.

framework-docs/modules/ROOT/pages/core/validation/beans-beans.adoc

@@ -38,7 +38,7 @@ manner, but through a nested property path. That means constructor binding creat
 the target object and any objects it contains.
 
 Constructor binding supports `List`, `Map`, and array arguments either converted from
-a single string, e.g. comma-separated list, or based on indexed keys such as
+a single string, for example, comma-separated list, or based on indexed keys such as
 `accounts[2].name` or `account[KEY].name`.
 
 Binding and conversion errors are reflected in the `BindingResult` of the `DataBinder`.

framework-docs/modules/ROOT/pages/core/validation/format.adoc

@@ -318,7 +318,7 @@ Kotlin::
 The `FormatterRegistry` is an SPI for registering formatters and converters.
 `FormattingConversionService` is an implementation of `FormatterRegistry` suitable for
 most environments. You can programmatically or declaratively configure this variant
-as a Spring bean, e.g. by using `FormattingConversionServiceFactoryBean`. Because this
+as a Spring bean, for example, by using `FormattingConversionServiceFactoryBean`. Because this
 implementation also implements `ConversionService`, you can directly configure it
 for use with Spring's `DataBinder` and the Spring Expression Language (SpEL).
 

framework-docs/modules/ROOT/pages/core/validation/validator.adoc

@@ -200,7 +200,7 @@ not involving a binding process. As of 6.1, this has been simplified through a n
 `Validator.validateObject(Object)` method which is available by default now, returning
 a simple ´Errors` representation which can be inspected: typically calling `hasErrors()`
 or the new `failOnError` method for turning the error summary message into an exception
-(e.g. `validator.validateObject(myObject).failOnError(IllegalArgumentException::new)`).
+(for example, `validator.validateObject(myObject).failOnError(IllegalArgumentException::new)`).
 
 
 

framework-docs/modules/ROOT/pages/data-access/jdbc/advanced.adoc

@@ -223,7 +223,7 @@ As of 6.1.2, Spring bypasses the default `getParameterType` resolution on Postgr
 MS SQL Server. This is a common optimization to avoid further roundtrips to the DBMS just
 for parameter type resolution which is known to make a very significant difference on
 PostgreSQL and MS SQL Server specifically, in particular for batch operations. If you
-happen to see a side effect e.g. when setting a byte array to null without specific type
+happen to see a side effect, for example, when setting a byte array to null without specific type
 indication, you may explicitly set the `spring.jdbc.getParameterType.ignore=false` flag
 as a system property (see above) to restore full `getParameterType` resolution.
 

framework-docs/modules/ROOT/pages/data-access/jdbc/connections.adoc

@@ -177,7 +177,7 @@ corresponding `DataSource` proxy class for the target connection pool: see
 This is particularly useful for potentially empty transactions without actual statement
 execution (never fetching an actual resource in such a scenario), and also in front of
 a routing `DataSource` which means to take the transaction-synchronized read-only flag
-and/or isolation level into account (e.g. `IsolationLevelDataSourceRouter`).
+and/or isolation level into account (for example, `IsolationLevelDataSourceRouter`).
 
 `LazyConnectionDataSourceProxy` also provides special support for a read-only connection
 pool to use during a read-only transaction, avoiding the overhead of switching the JDBC

framework-docs/modules/ROOT/pages/data-access/orm/jpa.adoc

@@ -175,7 +175,7 @@ a context-wide `LoadTimeWeaver` by using the `@EnableLoadTimeWeaving` annotation
 `context:load-time-weaver` XML element. Such a global weaver is automatically picked up
 by all JPA `LocalContainerEntityManagerFactoryBean` instances. The following example
 shows the preferred way of setting up a load-time weaver, delivering auto-detection
-of the platform (e.g. Tomcat's weaving-capable class loader or Spring's JVM agent)
+of the platform (for example, Tomcat's weaving-capable class loader or Spring's JVM agent)
 and automatic propagation of the weaver to all weaver-aware beans:
 
 [source,xml,indent=0,subs="verbatim,quotes"]
@@ -469,7 +469,7 @@ a non-invasiveness perspective and can feel more natural to JPA developers.
 What about providing JPA resources via constructors and other `@Autowired` injection points?
 
 `EntityManagerFactory` can easily be injected via constructors and `@Autowired` fields/methods
-as long as the target is defined as a bean, e.g. via `LocalContainerEntityManagerFactoryBean`.
+as long as the target is defined as a bean, for example, via `LocalContainerEntityManagerFactoryBean`.
 The injection point matches the original `EntityManagerFactory` definition by type as-is.
 
 However, an `@PersistenceContext`-style shared `EntityManager` reference is not available for

framework-docs/modules/ROOT/pages/data-access/r2dbc.adoc

@@ -469,10 +469,10 @@ Kotlin::
 
 NOTE: R2DBC itself does not support Collection-like values. Nevertheless,
 expanding a given `List` in the example above works for named parameters
-in Spring's R2DBC support, e.g. for use in `IN` clauses as shown above.
-However, inserting or updating array-typed columns (e.g. in Postgres)
+in Spring's R2DBC support, for example, for use in `IN` clauses as shown above.
+However, inserting or updating array-typed columns (for example, in Postgres)
 requires an array type that is supported by the underlying R2DBC driver:
-typically a Java array, e.g. `String[]` to update a `text[]` column.
+typically a Java array, for example, `String[]` to update a `text[]` column.
 Do not pass `Collection<String>` or the like as an array parameter.
 
 [[r2dbc-DatabaseClient-filter]]

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc

@@ -250,7 +250,7 @@ the proxy are intercepted. This means that self-invocation (in effect, a method
 the target object calling another method of the target object) does not lead to an actual
 transaction at runtime even if the invoked method is marked with `@Transactional`. Also,
 the proxy must be fully initialized to provide the expected behavior, so you should not
-rely on this feature in your initialization code -- e.g. in a `@PostConstruct` method.
+rely on this feature in your initialization code -- for example, in a `@PostConstruct` method.
 
 Consider using AspectJ mode (see the `mode` attribute in the following table) if you
 expect self-invocations to be wrapped with transactions as well. In this case, there is
@@ -564,7 +564,7 @@ transaction definitions from a base class as well. This effectively overrides
 the default transaction manager choice for any unqualified base class methods.
 
 Last but not least, such a type-level bean qualifier can serve multiple purposes,
-e.g. with a value of "order" it can be used for autowiring purposes (identifying
+for example, with a value of "order" it can be used for autowiring purposes (identifying
 the order repository) as well as transaction manager selection, as long as the
 target beans for autowiring as well as the associated transaction manager
 definitions declare the same qualifier value. Such a qualifier value only needs

framework-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-decl-explained.adoc

@@ -41,7 +41,7 @@ operations need to execute within the same Reactor context in the same reactive
 
 When configured with a `ReactiveTransactionManager`, all transaction-demarcated methods
 are expected to return a reactive pipeline. Void methods or regular return types need
-to be associated with a regular `PlatformTransactionManager`, e.g. through the
+to be associated with a regular `PlatformTransactionManager`, for example, through the
 `transactionManager` attribute of the corresponding `@Transactional` declarations.
 ====
 

framework-docs/modules/ROOT/pages/integration/cache/annotations.adoc

@@ -501,12 +501,12 @@ Placing this annotation on the class does not turn on any caching operation.
 An operation-level customization always overrides a customization set on `@CacheConfig`.
 Therefore, this gives three levels of customizations for each cache operation:
 
-* Globally configured, e.g. through `CachingConfigurer`: see next section.
+* Globally configured, for example, through `CachingConfigurer`: see next section.
 * At the class level, using `@CacheConfig`.
 * At the operation level.
 
 NOTE: Provider-specific settings are typically available on the `CacheManager` bean,
-e.g. on `CaffeineCacheManager`. These are effectively also global.
+for example, on `CaffeineCacheManager`. These are effectively also global.
 
 
 [[cache-annotation-enable]]

framework-docs/modules/ROOT/pages/integration/rest-clients.adoc

@@ -433,7 +433,7 @@ If no request factory is specified when the `RestClient` was built, it will use
 Otherwise, if the `java.net.http` module is loaded, it will use Java's `HttpClient`.
 Finally, it will resort to the simple default.
 
-TIP: Note that the `SimpleClientHttpRequestFactory` may raise an exception when accessing the status of a response that represents an error (e.g. 401).
+TIP: Note that the `SimpleClientHttpRequestFactory` may raise an exception when accessing the status of a response that represents an error (for example, 401).
 If this is an issue, use any of the alternative request factories.
 
 [[rest-webclient]]
@@ -966,7 +966,7 @@ method parameters:
 
 | `@RequestPart`
 | Add a request part, which may be a String (form field), `Resource` (file part),
-  Object (entity to be encoded, e.g. as JSON), `HttpEntity` (part content and headers),
+  Object (entity to be encoded, for example, as JSON), `HttpEntity` (part content and headers),
   a Spring `Part`, or Reactive Streams `Publisher` of any of the above.
 
 | `MultipartFile`

framework-docs/modules/ROOT/pages/integration/scheduling.adoc

@@ -483,7 +483,7 @@ seconds:
 ====
 When destroying the annotated bean or closing the application context, Spring Framework cancels
 scheduled tasks, which includes the next scheduled subscription to the `Publisher` as well
-as any past subscription that is still currently active (e.g. for long-running publishers
+as any past subscription that is still currently active (for example, for long-running publishers
 or even infinite publishers).
 ====
 

framework-docs/modules/ROOT/pages/languages/dynamic.adoc

@@ -10,7 +10,7 @@ objects.
 Spring's scripting support primarily targets Groovy and BeanShell. Beyond those
 specifically supported languages, the JSR-223 scripting mechanism is supported
 for integration with any JSR-223 capable language provider (as of Spring 4.2),
-e.g. JRuby.
+for example, JRuby.
 
 You can find fully working examples of where this dynamic language support can be
 immediately useful in xref:languages/dynamic.adoc#dynamic-language-scenarios[Scenarios].
@@ -179,7 +179,7 @@ Each of the supported languages has a corresponding `<lang:language/>` element:
 
 * `<lang:groovy/>` (Groovy)
 * `<lang:bsh/>` (BeanShell)
-* `<lang:std/>` (JSR-223, e.g. with JRuby)
+* `<lang:std/>` (JSR-223, for example, with JRuby)
 
 The exact attributes and child elements that are available for configuration depends on
 exactly which language the bean has been defined in (the language-specific sections

framework-docs/modules/ROOT/pages/overview.adoc

@@ -73,7 +73,7 @@ developers may choose to use instead of the Spring-specific mechanisms provided
 by the Spring Framework. Originally, those were based on common `javax` packages.
 
 As of Spring Framework 6.0, Spring has been upgraded to the Jakarta EE 9 level
-(e.g. Servlet 5.0+, JPA 3.0+), based on the `jakarta` namespace instead of the
+(for example, Servlet 5.0+, JPA 3.0+), based on the `jakarta` namespace instead of the
 traditional `javax` packages. With EE 9 as the minimum and EE 10 supported already,
 Spring is prepared to provide out-of-the-box support for the further evolution of
 the Jakarta EE APIs. Spring Framework 6.0 is fully compatible with Tomcat 10.1,