📝 文档

infra-docs/modules/ROOT/pages/core/aop-api.adoc

@@ -2,7 +2,7 @@
 = Infra AOP APIs
 :page-section-summary-toc: 1
 
-The previous chapter described the Spring's support for AOP with @AspectJ and schema-based
+The previous chapter described the Infra support for AOP with @AspectJ and schema-based
 aspect definitions. In this chapter, we discuss the lower-level Infra AOP APIs. For common
 applications, we recommend the use of Infra AOP with AspectJ pointcuts as described in the
 previous chapter.

infra-docs/modules/ROOT/pages/core/aop-api/advice.adoc

@@ -108,7 +108,7 @@ public interface MethodBeforeAdvice extends BeforeAdvice {
 }
 ----
 
-(Spring's API design would allow for
+(Infra API design would allow for
 field before advice, although the usual objects apply to field interception and it is
 unlikely for Spring to ever implement it.)
 

infra-docs/modules/ROOT/pages/core/aop-api/autoproxy.adoc

@@ -5,7 +5,7 @@ So far, we have considered explicit creation of AOP proxies by using a `ProxyFac
 similar factory bean.
 
 Spring also lets us use "`auto-proxy`" bean definitions, which can automatically
-proxy selected bean definitions. This is built on Spring's "`bean post processor`"
+proxy selected bean definitions. This is built on Infra "`bean post processor`"
 infrastructure, which enables modification of any bean definition as the container loads.
 
 In this model, you set up some special bean definitions in your XML bean definition file

infra-docs/modules/ROOT/pages/core/aop-api/pfb.adoc

@@ -2,7 +2,7 @@
 = Using the `ProxyFactoryBean` to Create AOP Proxies
 
 If you use the Infra IoC container (an `ApplicationContext` or `BeanFactory`) for your
-business objects (and you should be!), you want to use one of Spring's AOP
+business objects (and you should be!), you want to use one of Infra AOP
 `FactoryBean` implementations. (Remember that a factory bean introduces a layer of indirection, letting
 it create objects of a different type.)
 

infra-docs/modules/ROOT/pages/core/aop-api/pointcuts.adoc

@@ -8,7 +8,7 @@ This section describes how Spring handles the crucial pointcut concept.
 [[aop-api-concepts]]
 == Concepts
 
-Spring's pointcut model enables pointcut reuse independent of advice types. You can
+Infra pointcut model enables pointcut reuse independent of advice types. You can
 target different advice with the same pointcut.
 
 The `cn.taketoday.aop.Pointcut` interface is the central interface, used to

infra-docs/modules/ROOT/pages/core/aop-api/targetsource.adoc

@@ -88,7 +88,7 @@ application's classpath to use this feature. You can also subclass
 `cn.taketoday.aop.target.AbstractPoolingTargetSource` to support any other
 pooling API.
 
-NOTE: Commons Pool 1.5+ is also supported but is deprecated as of Spring Framework 4.0.
+NOTE: Commons Pool 1.5+ is also supported but is deprecated as of TODAY Framework 4.0.
 
 The following listing shows an example configuration:
 
@@ -209,7 +209,7 @@ should always consider wrapping a `ThreadLocal` in some other class and never di
 the `ThreadLocal` itself (except in the wrapper class). Also, you should
 always remember to correctly set and unset (where the latter simply involves a call to
 `ThreadLocal.set(null)`) the resource local to the thread. Unsetting should be done in
-any case, since not unsetting it might result in problematic behavior. Spring's
+any case, since not unsetting it might result in problematic behavior. Infra
 `ThreadLocal` support does this for you and should always be considered in favor of using
 `ThreadLocal` instances without other proper handling code.
 

infra-docs/modules/ROOT/pages/core/aop/aspectj-programmatic.adoc

@@ -3,7 +3,7 @@
 
 In addition to declaring aspects in your configuration by using either `<aop:config>`
 or `<aop:aspectj-autoproxy>`, it is also possible to programmatically create proxies
-that advise target objects. For the full details of Spring's AOP API, see the
+that advise target objects. For the full details of Infra AOP API, see the
 xref:core/aop-api.adoc[next chapter]. Here, we want to focus on the ability to automatically
 create proxies by using @AspectJ aspects.
 

infra-docs/modules/ROOT/pages/core/aop/ataspectj/at-aspectj.adoc

@@ -42,7 +42,7 @@ via `@Bean` methods in `@Configuration` classes, or have Spring autodetect them
 classpath scanning -- the same as any other Spring-managed bean. However, note that the
 `@Aspect` annotation is not sufficient for autodetection in the classpath. For that
 purpose, you need to add a separate `@Component` annotation (or, alternatively, a custom
-stereotype annotation that qualifies, as per the rules of Spring's component scanner).
+stereotype annotation that qualifies, as per the rules of Infra component scanner).
 
 .Advising aspects with other aspects?
 NOTE: In Infra AOP, aspects themselves cannot be the targets of advice from other

infra-docs/modules/ROOT/pages/core/aop/ataspectj/pointcuts.adoc

@@ -86,7 +86,7 @@ proxy (which is bound to `target`).
 
 [NOTE]
 ====
-Due to the proxy-based nature of Spring's AOP framework, calls within the target object
+Due to the proxy-based nature of Infra 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 are intercepted (and even package-visible methods, if necessary). However,
@@ -98,7 +98,7 @@ potential non-public interactions through proxies, it needs to be defined accord
 
 If your interception needs include method calls or even constructors within the target
 class, consider the use of Spring-driven xref:core/aop/using-aspectj.adoc#aop-aj-ltw[native AspectJ weaving] instead
-of Spring's proxy-based AOP framework. This constitutes a different mode of AOP usage
+of Infra proxy-based AOP framework. This constitutes a different mode of AOP usage
 with different characteristics, so be sure to make yourself familiar with weaving
 before making a decision.
 ====
@@ -126,7 +126,7 @@ AspectJ defines and is, therefore, not available for aspects declared in the `@A
 
 The `bean` PCD operates at the instance level (building on the Spring bean name
 concept) rather than at the type level only (to which weaving-based AOP is limited).
-Instance-based pointcut designators are a special capability of Spring's
+Instance-based pointcut designators are a special capability of Infra
 proxy-based AOP framework and its close integration with the Spring bean factory, where
 it is natural and straightforward to identify specific beans by name.
 ====

infra-docs/modules/ROOT/pages/core/aop/proxying.adoc

@@ -18,7 +18,7 @@ you can do so. However, you should consider the following issues:
 * As of Spring 4.0, the constructor of your proxied object is NOT called twice anymore,
   since the CGLIB proxy instance is created through Objenesis. Only if your JVM does
   not allow for constructor bypassing, you might see double invocations and
-  corresponding debug log entries from Spring's AOP support.
+  corresponding debug log entries from Infra AOP support.
 
 To force the use of CGLIB proxies, set the value of the `proxy-target-class` attribute
 of the `<aop:config>` element to true, as follows:

infra-docs/modules/ROOT/pages/core/aop/schema.adoc

@@ -18,7 +18,7 @@ an `<aop:config>` element (you can have more than one `<aop:config>` element in
 application context configuration). An `<aop:config>` element can contain pointcut,
 advisor, and aspect elements (note that these must be declared in that order).
 
-WARNING: The `<aop:config>` style of configuration makes heavy use of Spring's
+WARNING: The `<aop:config>` style of configuration makes heavy use of Infra
 xref:core/aop-api/autoproxy.adoc[auto-proxying] mechanism. This can cause issues (such as advice
 not being woven) if you already use explicit auto-proxying through the use of
 `BeanNameAutoProxyCreator` or something similar. The recommended usage pattern is to
@@ -506,7 +506,7 @@ preceding advice for a particular join point:
     http://www.springframework.org/schema/aop
     https://www.springframework.org/schema/aop/spring-aop.xsd">
 
-  <!-- this is the object that will be proxied by Spring's AOP infrastructure -->
+  <!-- this is the object that will be proxied by Infra AOP infrastructure -->
   <bean id="personService" class="com.xyz.service.DefaultPersonService"/>
 
   <!-- this is the actual advice itself -->

infra-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc

@@ -8,8 +8,8 @@ how to write your own custom XML bean definition parsers and
 integrate such parsers into the Infra IoC container.
 
 To facilitate authoring configuration files that use a schema-aware XML editor,
-Spring's extensible XML configuration mechanism is based on XML Schema. If you are not
-familiar with Spring's current XML configuration extensions that come with the standard
+Infra extensible XML configuration mechanism is based on XML Schema. If you are not
+familiar with Infra current XML configuration extensions that come with the standard
 Spring distribution, you should first read the previous section on xref:core/appendix/xsd-schemas.adoc[XML Schemas].
 
 
@@ -40,7 +40,7 @@ through the basic steps of making a custom extension.)
 [[xsd-custom-schema]]
 == Authoring the Schema
 
-Creating an XML configuration extension for use with Spring's IoC container starts with
+Creating an XML configuration extension for use with Infra IoC container starts with
 authoring an XML Schema to describe the extension. For our example, we use the following schema
 to configure `SimpleDateFormat` objects:
 

infra-docs/modules/ROOT/pages/core/appendix/xsd-schemas.adoc

@@ -48,7 +48,7 @@ Consider the following bean definition:
 The preceding configuration uses a Spring `FactoryBean` implementation (the
 `FieldRetrievingFactoryBean`) to set the value of the `isolation` property on a bean
 to the value of the `java.sql.Connection.TRANSACTION_SERIALIZABLE` constant. This is
-all well and good, but it is verbose and (unnecessarily) exposes Spring's internal
+all well and good, but it is verbose and (unnecessarily) exposes Infra internal
 plumbing to the end user.
 
 The following XML Schema-based version is more concise, clearly expresses the
@@ -481,8 +481,8 @@ If no `set-class` attribute is supplied, the container chooses a `Set` implement
 [[xsd-schemas-aop]]
 == The `aop` Schema
 
-The `aop` tags deal with configuring all things AOP in Spring, including Spring's
-own proxy-based AOP framework and Spring's integration with the AspectJ AOP framework.
+The `aop` tags deal with configuring all things AOP in Spring, including Infra
+own proxy-based AOP framework and Infra integration with the AspectJ AOP framework.
 These tags are comprehensively covered in the chapter entitled xref:core/aop.adoc[Aspect Oriented Programming with Spring]
 .
 
@@ -559,20 +559,20 @@ not create multiple properties placeholders. Rather, each module should contribu
 
 This element activates the Spring infrastructure to detect annotations in bean classes:
 
-* Spring's xref:core/beans/basics.adoc#beans-factory-metadata[`@Configuration`] model
+* Infra xref:core/beans/basics.adoc#beans-factory-metadata[`@Configuration`] model
 * xref:core/beans/annotation-config.adoc[`@Autowired`/`@Inject`], `@Value`, and `@Lookup`
 * JSR-250's `@Resource`, `@PostConstruct`, and `@PreDestroy` (if available)
 * JAX-WS's `@WebServiceRef` and EJB 3's `@EJB` (if available)
 * JPA's `@PersistenceContext` and `@PersistenceUnit` (if available)
-* Spring's xref:core/beans/context-introduction.adoc#context-functionality-events-annotation[`@EventListener`]
+* Infra xref:core/beans/context-introduction.adoc#context-functionality-events-annotation[`@EventListener`]
 
 Alternatively, you can choose to explicitly activate the individual `BeanPostProcessors`
 for those annotations.
 
-NOTE: This element does not activate processing of Spring's
+NOTE: This element does not activate processing of Infra
 xref:data-access/transaction/declarative/annotations.adoc[`@Transactional`] annotation;
 you can use the <<data-access.adoc#tx-decl-explained, `<tx:annotation-driven/>`>>
-element for that purpose. Similarly, Spring's
+element for that purpose. Similarly, Infra
 xref:integration/cache/annotations.adoc[caching annotations] need to be explicitly
 xref:integration/cache/annotations.adoc#cache-annotation-enable[enabled] as well.
 

infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-primary.adoc

@@ -2,7 +2,7 @@
 = Fine-tuning Annotation-based Autowiring with `@Primary` or `@Fallback`
 
 Because autowiring by type may lead to multiple candidates, it is often necessary to have
-more control over the selection process. One way to accomplish this is with Spring's
+more control over the selection process. One way to accomplish this is with Infra
 `@Primary` annotation. `@Primary` indicates that a particular bean should be given
 preference when multiple beans are candidates to be autowired to a single-valued
 dependency. If exactly one primary bean exists among the candidates, it becomes the

infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-qualifiers.adoc

@@ -4,7 +4,7 @@
 `@Primary` and `@Fallback` are effective ways to use autowiring by type with several
 instances when one primary (or non-fallback) candidate can be determined.
 
-When you need more control over the selection process, you can use Spring's `@Qualifier`
+When you need more control over the selection process, you can use Infra `@Qualifier`
 annotation. You can associate qualifier values with specific arguments, narrowing the set
 of type matches so that a specific bean is chosen for each argument. In the simplest case,
 this can be a plain descriptive value, as shown in the following example:
@@ -138,7 +138,7 @@ matching an `account` qualifier against beans marked with the same qualifier lab
 
 For beans that are themselves defined as a collection, `Map`, or array type, `@Resource`
 is a fine solution, referring to the specific collection or array bean by unique name.
-That said, as of 4.3, you can match collection, `Map`, and array types through Spring's
+That said, as of 4.3, you can match collection, `Map`, and array types through Infra
 `@Autowired` type matching algorithm as well, as long as the element type information
 is preserved in `@Bean` return type signatures or collection inheritance hierarchies.
 In this case, you can use qualifier values to select among same-typed collections,

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

@@ -3,7 +3,7 @@
 
 [NOTE]
 ====
-JSR 330's `@Inject` annotation can be used in place of Spring's `@Autowired` annotation in the
+JSR 330's `@Inject` annotation can be used in place of Infra `@Autowired` annotation in the
 examples included in this section. See xref:core/beans/standard-annotations.adoc[here] for more details.
 ====
 
@@ -265,7 +265,7 @@ that can be optionally overridden via dependency injection.
 
 [[beans-autowired-annotation-constructor-resolution]]
 Injected constructor and factory method arguments are a special case since the `required`
-attribute in `@Autowired` has a somewhat different meaning due to Spring's constructor
+attribute in `@Autowired` has a somewhat different meaning due to Infra constructor
 resolution algorithm that may potentially deal with multiple constructors. Constructor
 and factory method arguments are effectively required by default but with a few special
 rules in a single-constructor scenario, such as multi-element injection points (arrays,

infra-docs/modules/ROOT/pages/core/beans/annotation-config/custom-autowire-configurer.adoc

@@ -3,7 +3,7 @@
 
 {today-framework-api}/beans/factory/annotation/CustomAutowireConfigurer.html[`CustomAutowireConfigurer`]
 is a `BeanFactoryPostProcessor` that lets you register your own custom qualifier
-annotation types, even if they are not annotated with Spring's `@Qualifier` annotation.
+annotation types, even if they are not annotated with Infra `@Qualifier` annotation.
 The following example shows how to use `CustomAutowireConfigurer`:
 
 [source,xml,indent=0,subs="verbatim,quotes"]

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

@@ -61,10 +61,10 @@ public class SimpleMovieLister {
 
 NOTE: The name provided with the annotation is resolved as a bean name by the
 `ApplicationContext` of which the `CommonAnnotationBeanPostProcessor` is aware.
-The names can be resolved through JNDI if you configure Spring's
+The names can be resolved through JNDI if you configure Infra
 {today-framework-api}/jndi/support/SimpleJndiBeanFactory.html[`SimpleJndiBeanFactory`]
 explicitly. However, we recommend that you rely on the default behavior and
-use Spring's JNDI lookup capabilities to preserve the level of indirection.
+use Infra JNDI lookup capabilities to preserve the level of indirection.
 
 In the exclusive case of `@Resource` usage with no explicit name specified, and similar
 to `@Autowired`, `@Resource` finds a primary type match instead of a specific named bean

infra-docs/modules/ROOT/pages/core/beans/annotation-config/value-annotations.adoc

@@ -79,7 +79,7 @@ placeholder could not be resolved. It is also possible to use methods like
 `setPlaceholderPrefix`, `setPlaceholderSuffix`, `setValueSeparator`, or
 `setEscapeCharacter` to customize placeholders.
 
-NOTE: Spring Boot configures by default a `PropertySourcesPlaceholderConfigurer` bean that
+NOTE: Infra App configures by default a `PropertySourcesPlaceholderConfigurer` bean that
 will get properties from `application.properties` and `application.yml` files.
 
 Built-in converter support provided by Spring allows simple type conversion (to `Integer`

infra-docs/modules/ROOT/pages/core/beans/basics.adoc

@@ -133,7 +133,7 @@ ApplicationContext context = new ClassPathXmlApplicationContext("services.xml",
 
 [NOTE]
 ====
-After you learn about Spring's IoC container, you may want to know more about Spring's
+After you learn about Infra IoC container, you may want to know more about Infra
 `Resource` abstraction (as described in
 xref:core/resources.adoc[Resources])
 which provides a convenient mechanism for reading an InputStream from locations defined
@@ -255,7 +255,7 @@ of XML namespaces provided by Spring -- for example, the `context` and `util` na
 === The Groovy Bean Definition DSL
 
 As a further example for externalized configuration metadata, bean definitions can also
-be expressed in Spring's Groovy Bean Definition DSL, as known from the Grails framework.
+be expressed in Infra Groovy Bean Definition DSL, as known from the Grails framework.
 Typically, such configuration live in a ".groovy" file with the structure shown in the
 following example:
 
@@ -281,7 +281,7 @@ beans {
 ----
 
 This configuration style is largely equivalent to XML bean definitions and even
-supports Spring's XML configuration namespaces. It also allows for importing XML
+supports Infra XML configuration namespaces. It also allows for importing XML
 bean definition files through an `importBeans` directive.
 
 
@@ -369,7 +369,7 @@ You can then use `getBean` to retrieve instances of your beans. The `Application
 interface has a few other methods for retrieving beans, but, ideally, your application
 code should never use them. Indeed, your application code should have no calls to the
 `getBean()` method at all and thus have no dependency on Infra APIs at all. For example,
-Spring's integration with web frameworks provides dependency injection for various web
+Infra integration with web frameworks provides dependency injection for various web
 framework components such as controllers and JSF-managed beans, letting you declare
 a dependency on a specific bean through metadata (such as an autowiring annotation).