From 9f7cb7fd2b0326b98187b2314281e6b54061ce79 Mon Sep 17 00:00:00 2001 From: Harry Yang Date: Tue, 16 Apr 2024 17:58:59 +0800 Subject: [PATCH] =?UTF-8?q?:memo:=20=E6=96=87=E6=A1=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../modules/ROOT/pages/core/aop-api.adoc | 2 +- .../ROOT/pages/core/aop-api/advice.adoc | 2 +- .../ROOT/pages/core/aop-api/autoproxy.adoc | 2 +- .../modules/ROOT/pages/core/aop-api/pfb.adoc | 2 +- .../ROOT/pages/core/aop-api/pointcuts.adoc | 2 +- .../ROOT/pages/core/aop-api/targetsource.adoc | 4 +- .../pages/core/aop/aspectj-programmatic.adoc | 2 +- .../pages/core/aop/ataspectj/at-aspectj.adoc | 2 +- .../pages/core/aop/ataspectj/pointcuts.adoc | 6 +- .../modules/ROOT/pages/core/aop/proxying.adoc | 2 +- .../modules/ROOT/pages/core/aop/schema.adoc | 4 +- .../ROOT/pages/core/appendix/xml-custom.adoc | 6 +- .../ROOT/pages/core/appendix/xsd-schemas.adoc | 14 +- .../annotation-config/autowired-primary.adoc | 2 +- .../autowired-qualifiers.adoc | 4 +- .../beans/annotation-config/autowired.adoc | 4 +- .../custom-autowire-configurer.adoc | 2 +- .../beans/annotation-config/resource.adoc | 4 +- .../annotation-config/value-annotations.adoc | 2 +- .../modules/ROOT/pages/core/beans/basics.adoc | 8 +- .../ROOT/pages/core/beans/beanfactory.adoc | 8 +- .../pages/core/beans/classpath-scanning.adoc | 8 +- .../core/beans/context-introduction.adoc | 18 +-- .../core/beans/context-load-time-weaver.adoc | 2 +- .../beans/dependencies/factory-autowire.adoc | 2 +- .../factory-method-injection.adoc | 2 +- .../factory-properties-detailed.adoc | 8 +- .../ROOT/pages/core/beans/environment.adoc | 12 +- .../pages/core/beans/factory-extension.adoc | 2 +- .../ROOT/pages/core/beans/factory-nature.adoc | 4 +- .../ROOT/pages/core/beans/factory-scopes.adoc | 6 +- .../pages/core/beans/java/basic-concepts.adoc | 4 +- .../core/beans/java/bean-annotation.adoc | 2 +- .../java/composing-configuration-classes.adoc | 6 +- .../beans/java/instantiating-container.adoc | 4 +- .../core/beans/standard-annotations.adoc | 14 +- .../modules/ROOT/pages/core/null-safety.adoc | 2 +- .../modules/ROOT/pages/core/resources.adoc | 12 +- .../modules/ROOT/pages/core/spring-jcl.adoc | 2 +- .../modules/ROOT/pages/core/validation.adoc | 6 +- .../pages/core/validation/beans-beans.adoc | 4 +- .../pages/core/validation/beanvalidation.adoc | 2 +- .../ROOT/pages/core/validation/format.adoc | 2 +- .../ROOT/pages/core/validation/validator.adoc | 2 +- .../modules/ROOT/pages/data-access.adoc | 6 +- .../ROOT/pages/data-access/appendix.adoc | 4 +- .../modules/ROOT/pages/data-access/dao.adoc | 2 +- .../modules/ROOT/pages/data-access/jdbc.adoc | 4 +- .../pages/data-access/jdbc/connections.adoc | 6 +- .../ROOT/pages/data-access/jdbc/core.adoc | 6 +- .../jdbc/embedded-database-support.adoc | 4 +- .../ROOT/pages/data-access/jdbc/packages.adoc | 2 +- .../data-access/jdbc/parameter-handling.adoc | 2 +- .../ROOT/pages/data-access/orm/general.adoc | 6 +- .../ROOT/pages/data-access/orm/hibernate.adoc | 32 ++--- .../pages/data-access/orm/introduction.adoc | 10 +- .../ROOT/pages/data-access/orm/jpa.adoc | 20 +-- .../modules/ROOT/pages/data-access/oxm.adoc | 10 +- .../ROOT/pages/data-access/transaction.adoc | 12 +- .../application-server-integration.adoc | 6 +- .../data-access/transaction/declarative.adoc | 18 +-- .../transaction/declarative/annotations.adoc | 10 +- .../transaction/declarative/aspectj.adoc | 6 +- .../declarative/first-example.adoc | 2 +- .../transaction/declarative/rolling-back.adoc | 14 +- .../declarative/tx-decl-explained.adoc | 8 +- .../declarative/tx-propagation.adoc | 2 +- .../data-access/transaction/motivation.adoc | 20 +-- .../data-access/transaction/programmatic.adoc | 6 +- .../data-access/transaction/resources.adoc | 6 +- .../solutions-to-common-problems.adoc | 2 +- .../data-access/transaction/strategies.adoc | 14 +- .../transaction/tx-decl-vs-prog.adoc | 2 +- .../tx-resource-synchronization.adoc | 12 +- .../modules/ROOT/pages/integration.adoc | 4 +- .../ROOT/pages/integration/appendix.adoc | 2 +- .../modules/ROOT/pages/integration/cache.adoc | 4 +- .../pages/integration/cache/annotations.adoc | 6 +- .../ROOT/pages/integration/cache/jsr-107.adoc | 20 +-- .../cache/store-configuration.adoc | 2 +- .../pages/integration/cache/strategies.adoc | 2 +- .../modules/ROOT/pages/integration/cds.adoc | 2 +- .../pages/integration/checkpoint-restore.adoc | 2 +- .../modules/ROOT/pages/integration/email.adoc | 10 +- .../modules/ROOT/pages/integration/jmx.adoc | 2 +- .../ROOT/pages/integration/jmx/exporting.adoc | 4 +- .../pages/integration/jmx/notifications.adoc | 12 +- .../ROOT/pages/integration/rest-clients.adoc | 6 +- .../ROOT/pages/integration/scheduling.adoc | 32 ++--- .../modules/ROOT/pages/languages/dynamic.adoc | 76 +++++----- .../modules/ROOT/pages/languages/groovy.adoc | 2 +- infra-docs/modules/ROOT/pages/overview.adoc | 4 +- infra-docs/modules/ROOT/pages/testing.adoc | 4 +- .../ROOT/pages/testing/annotations.adoc | 2 +- .../integration-junit-jupiter.adoc | 90 ++++++------ .../annotations/integration-junit4.adoc | 12 +- .../testing/annotations/integration-meta.adoc | 24 ++-- .../annotations/integration-spring.adoc | 6 +- .../annotation-aftertransaction.adoc | 2 +- .../annotation-beanoverriding.adoc | 8 +- .../annotation-beforetransaction.adoc | 2 +- .../annotation-bootstrapwith.adoc | 2 +- .../annotation-dirtiescontext.adoc | 16 +-- .../annotation-disabledinaotmode.adoc | 4 +- .../annotation-recordapplicationevents.adoc | 2 +- .../annotation-rollback.adoc | 2 +- .../annotation-sqlmergemode.adoc | 4 +- .../annotations/integration-standard.adoc | 4 +- .../ROOT/pages/testing/integration.adoc | 28 ++-- .../ROOT/pages/testing/introduction.adoc | 2 +- .../modules/ROOT/pages/testing/resources.adoc | 6 +- .../pages/testing/spring-mvc-test-client.adoc | 2 +- .../testing/spring-mvc-test-framework.adoc | 2 +- .../server-filters.adoc | 2 +- .../server-htmlunit.adoc | 2 +- .../server-htmlunit/mah.adoc | 4 +- .../server-htmlunit/webdriver.adoc | 4 +- .../server-resources.adoc | 4 +- .../server-setup-options.adoc | 16 +-- .../server-setup-steps.adoc | 2 +- .../spring-mvc-test-framework/server.adoc | 2 +- .../vs-end-to-end-integration-tests.adoc | 8 +- .../vs-streaming-response.adoc | 2 +- .../ROOT/pages/testing/support-jdbc.adoc | 6 +- .../pages/testing/testcontext-framework.adoc | 6 +- .../testing/testcontext-framework/aot.adoc | 16 +-- .../application-events.adoc | 10 +- .../testcontext-framework/bootstrapping.adoc | 4 +- .../testcontext-framework/ctx-management.adoc | 10 +- .../ctx-management/caching.adoc | 16 +-- .../ctx-management/context-customizers.adoc | 10 +- .../dynamic-property-sources.adoc | 12 +- .../ctx-management/env-profiles.adoc | 10 +- .../ctx-management/failure-threshold.adoc | 4 +- .../ctx-management/groovy.adoc | 8 +- .../ctx-management/hierarchies.adoc | 16 +-- .../ctx-management/inheritance.adoc | 12 +- .../ctx-management/initializers.adoc | 8 +- .../ctx-management/javaconfig.adoc | 8 +- .../ctx-management/mixed-config.adoc | 10 +- .../ctx-management/property-sources.adoc | 14 +- .../ctx-management/web-mocks.adoc | 4 +- .../ctx-management/web.adoc | 14 +- .../ctx-management/xml.adoc | 6 +- .../testcontext-framework/executing-sql.adoc | 30 ++-- .../testcontext-framework/fixture-di.adoc | 14 +- .../key-abstractions.adoc | 8 +- .../parallel-test-execution.adoc | 14 +- .../support-classes.adoc | 130 +++++++++--------- .../testcontext-framework/tel-config.adoc | 20 +-- .../test-execution-events.adoc | 10 +- .../testing/testcontext-framework/tx.adoc | 36 ++--- .../web-scoped-beans.adoc | 6 +- .../modules/ROOT/pages/testing/unit.adoc | 24 ++-- .../ROOT/pages/testing/webtestclient.adoc | 8 +- .../modules/ROOT/pages/web/integration.adoc | 44 +++--- .../modules/ROOT/pages/web/webmvc-client.adoc | 2 +- .../ROOT/pages/web/webmvc-functional.adoc | 16 +-- .../modules/ROOT/pages/web/webmvc-test.adoc | 6 +- .../pages/web/webmvc-view/mvc-document.adoc | 4 +- .../ROOT/pages/web/webmvc-view/mvc-feeds.adoc | 2 +- .../pages/web/webmvc-view/mvc-freemarker.adoc | 18 +-- .../pages/web/webmvc-view/mvc-jackson.adoc | 2 +- .../ROOT/pages/web/webmvc-view/mvc-xslt.adoc | 14 +- .../ROOT/pages/web/webmvc/filters.adoc | 12 +- .../ROOT/pages/web/webmvc/mvc-ann-async.adoc | 12 +- .../web/webmvc/mvc-ann-rest-exceptions.adoc | 4 +- .../ROOT/pages/web/webmvc/mvc-caching.adoc | 2 +- .../web/webmvc/mvc-config/advanced-java.adoc | 2 +- .../web/webmvc/mvc-config/advanced-xml.adoc | 2 +- .../pages/web/webmvc/mvc-config/enable.adoc | 2 +- .../web/webmvc/mvc-config/interceptors.adoc | 2 +- .../webmvc/mvc-config/message-converters.adoc | 2 +- .../webmvc/mvc-config/static-resources.adoc | 2 +- .../web/webmvc/mvc-controller/ann-advice.adoc | 2 +- .../mvc-controller/ann-exceptionhandler.adoc | 2 +- .../mvc-controller/ann-methods/arguments.adoc | 6 +- .../mvc-controller/ann-methods/jackson.adoc | 2 +- .../ann-methods/modelattrib-method-args.adoc | 4 +- .../ann-methods/multipart-forms.adoc | 4 +- .../ann-methods/requestbody.adoc | 2 +- .../ann-methods/typeconversion.adoc | 2 +- .../mvc-controller/ann-requestmapping.adoc | 6 +- .../webmvc/mvc-controller/ann-validation.adoc | 2 +- .../pages/web/webmvc/mvc-controller/ann.adoc | 4 +- .../ROOT/pages/web/webmvc/mvc-servlet.adoc | 12 +- .../pages/web/webmvc/mvc-servlet/config.adoc | 2 +- .../webmvc/mvc-servlet/container-config.adoc | 4 +- .../webmvc/mvc-servlet/exceptionhandlers.adoc | 2 +- .../mvc-servlet/handlermapping-path.adoc | 2 +- .../webmvc/mvc-servlet/localeresolver.adoc | 8 +- .../web/webmvc/mvc-servlet/multipart.adoc | 2 +- .../mvc-servlet/special-bean-types.adoc | 2 +- .../web/webmvc/mvc-servlet/themeresolver.adoc | 6 +- .../web/webmvc/mvc-servlet/viewresolver.adoc | 2 +- .../pages/web/webmvc/mvc-uri-building.adoc | 2 +- .../ROOT/pages/web/websocket/server.adoc | 14 +- 197 files changed, 836 insertions(+), 838 deletions(-) diff --git a/infra-docs/modules/ROOT/pages/core/aop-api.adoc b/infra-docs/modules/ROOT/pages/core/aop-api.adoc index d85736946a..445cad3299 100644 --- a/infra-docs/modules/ROOT/pages/core/aop-api.adoc +++ b/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. diff --git a/infra-docs/modules/ROOT/pages/core/aop-api/advice.adoc b/infra-docs/modules/ROOT/pages/core/aop-api/advice.adoc index 44293edc9e..be9b09048d 100644 --- a/infra-docs/modules/ROOT/pages/core/aop-api/advice.adoc +++ b/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.) diff --git a/infra-docs/modules/ROOT/pages/core/aop-api/autoproxy.adoc b/infra-docs/modules/ROOT/pages/core/aop-api/autoproxy.adoc index 9422e765f2..6c7a800d17 100644 --- a/infra-docs/modules/ROOT/pages/core/aop-api/autoproxy.adoc +++ b/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 diff --git a/infra-docs/modules/ROOT/pages/core/aop-api/pfb.adoc b/infra-docs/modules/ROOT/pages/core/aop-api/pfb.adoc index 11cdc9ed05..64d2d3b4cc 100644 --- a/infra-docs/modules/ROOT/pages/core/aop-api/pfb.adoc +++ b/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.) diff --git a/infra-docs/modules/ROOT/pages/core/aop-api/pointcuts.adoc b/infra-docs/modules/ROOT/pages/core/aop-api/pointcuts.adoc index 1bdb599dd0..3abbeb0b63 100644 --- a/infra-docs/modules/ROOT/pages/core/aop-api/pointcuts.adoc +++ b/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 diff --git a/infra-docs/modules/ROOT/pages/core/aop-api/targetsource.adoc b/infra-docs/modules/ROOT/pages/core/aop-api/targetsource.adoc index 558f965898..2c740b8693 100644 --- a/infra-docs/modules/ROOT/pages/core/aop-api/targetsource.adoc +++ b/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. diff --git a/infra-docs/modules/ROOT/pages/core/aop/aspectj-programmatic.adoc b/infra-docs/modules/ROOT/pages/core/aop/aspectj-programmatic.adoc index 0fe454afa4..073a1cb1f5 100644 --- a/infra-docs/modules/ROOT/pages/core/aop/aspectj-programmatic.adoc +++ b/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 `` or ``, 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. diff --git a/infra-docs/modules/ROOT/pages/core/aop/ataspectj/at-aspectj.adoc b/infra-docs/modules/ROOT/pages/core/aop/ataspectj/at-aspectj.adoc index ba69161f23..65e5e8f02b 100644 --- a/infra-docs/modules/ROOT/pages/core/aop/ataspectj/at-aspectj.adoc +++ b/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 diff --git a/infra-docs/modules/ROOT/pages/core/aop/ataspectj/pointcuts.adoc b/infra-docs/modules/ROOT/pages/core/aop/ataspectj/pointcuts.adoc index 33c0b7549c..db9aded932 100644 --- a/infra-docs/modules/ROOT/pages/core/aop/ataspectj/pointcuts.adoc +++ b/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. ==== diff --git a/infra-docs/modules/ROOT/pages/core/aop/proxying.adoc b/infra-docs/modules/ROOT/pages/core/aop/proxying.adoc index 408744b5f7..b749c775a4 100644 --- a/infra-docs/modules/ROOT/pages/core/aop/proxying.adoc +++ b/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 `` element to true, as follows: diff --git a/infra-docs/modules/ROOT/pages/core/aop/schema.adoc b/infra-docs/modules/ROOT/pages/core/aop/schema.adoc index fb30453a7b..3ba0b9c636 100644 --- a/infra-docs/modules/ROOT/pages/core/aop/schema.adoc +++ b/infra-docs/modules/ROOT/pages/core/aop/schema.adoc @@ -18,7 +18,7 @@ an `` element (you can have more than one `` element in application context configuration). An `` element can contain pointcut, advisor, and aspect elements (note that these must be declared in that order). -WARNING: The `` style of configuration makes heavy use of Spring's +WARNING: The `` 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"> - + diff --git a/infra-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc b/infra-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc index c60210352a..f0214b4789 100644 --- a/infra-docs/modules/ROOT/pages/core/appendix/xml-custom.adoc +++ b/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: diff --git a/infra-docs/modules/ROOT/pages/core/appendix/xsd-schemas.adoc b/infra-docs/modules/ROOT/pages/core/appendix/xsd-schemas.adoc index 83463f5a35..4c0c857933 100644 --- a/infra-docs/modules/ROOT/pages/core/appendix/xsd-schemas.adoc +++ b/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 <`>> -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. diff --git a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-primary.adoc b/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-primary.adoc index e00128b61c..8560b81cb2 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-primary.adoc +++ b/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 diff --git a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-qualifiers.adoc b/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-qualifiers.adoc index 54575bd143..55d257f22b 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired-qualifiers.adoc +++ b/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, diff --git a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired.adoc b/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired.adoc index 87ca885225..816778f1c1 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/autowired.adoc +++ b/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, diff --git a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/custom-autowire-configurer.adoc b/infra-docs/modules/ROOT/pages/core/beans/annotation-config/custom-autowire-configurer.adoc index 3fcf43cb44..5ba3b6d6fc 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/custom-autowire-configurer.adoc +++ b/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"] diff --git a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/resource.adoc b/infra-docs/modules/ROOT/pages/core/beans/annotation-config/resource.adoc index d254ec83fd..b1beb0dcd5 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/resource.adoc +++ b/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 diff --git a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/value-annotations.adoc b/infra-docs/modules/ROOT/pages/core/beans/annotation-config/value-annotations.adoc index 6b0b172b78..c58f5ea1d7 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/annotation-config/value-annotations.adoc +++ b/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` diff --git a/infra-docs/modules/ROOT/pages/core/beans/basics.adoc b/infra-docs/modules/ROOT/pages/core/beans/basics.adoc index 5434131dae..7ebe7a1247 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/basics.adoc +++ b/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). diff --git a/infra-docs/modules/ROOT/pages/core/beans/beanfactory.adoc b/infra-docs/modules/ROOT/pages/core/beans/beanfactory.adoc index 26d5fffc3e..05e7b13fc3 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/beanfactory.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/beanfactory.adoc @@ -1,7 +1,7 @@ [[beans-beanfactory]] = The `BeanFactory` API -The `BeanFactory` API provides the underlying basis for Spring's IoC functionality. +The `BeanFactory` API provides the underlying basis for Infra IoC functionality. Its specific contracts are mostly used in integration with other parts of Spring and related third-party frameworks, and its `DefaultListableBeanFactory` implementation is a key delegate within the higher-level `GenericApplicationContext` container. @@ -18,7 +18,7 @@ implementation do not make assumptions about the configuration format or any component annotations to be used. All of these flavors come in through extensions (such as `XmlBeanDefinitionReader` and `AutowiredAnnotationBeanPostProcessor`) and operate on shared `BeanDefinition` objects as a core metadata representation. -This is the essence of what makes Spring's container so flexible and extensible. +This is the essence of what makes Infra container so flexible and extensible. @@ -31,7 +31,7 @@ This section explains the differences between the `BeanFactory` and You should use an `ApplicationContext` unless you have a good reason for not doing so, with `GenericApplicationContext` and its subclass `AnnotationConfigApplicationContext` as the common implementations for custom bootstrapping. These are the primary entry -points to Spring's core container for all common purposes: loading of configuration +points to Infra core container for all common purposes: loading of configuration files, triggering a classpath scan, programmatically registering bean definitions and annotated classes, and (as of 5.0) registering functional bean definitions. @@ -138,6 +138,6 @@ container functionality in a typical enterprise setup. An `AnnotationConfigApplicationContext` has all common annotation post-processors registered and may bring in additional processors underneath the covers through configuration annotations, such as `@EnableTransactionManagement`. -At the abstraction level of Spring's annotation-based configuration model, +At the abstraction level of Infra annotation-based configuration model, the notion of bean post-processors becomes a mere internal container detail. ==== diff --git a/infra-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc b/infra-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc index b07f58e396..069c445863 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/classpath-scanning.adoc @@ -74,7 +74,7 @@ the `@RestController` annotation from Web MVC is composed of `@Controller` and In addition, composed annotations can optionally redeclare attributes from meta-annotations to allow customization. This can be particularly useful when you -want to only expose a subset of the meta-annotation's attributes. For example, Spring's +want to only expose a subset of the meta-annotation's attributes. For example, Infra `@SessionScope` annotation hard codes the scope name to `session` but still allows customization of the `proxyMode`. The following listing shows the definition of the `SessionScope` annotation: @@ -192,7 +192,7 @@ The following alternative uses XML: TIP: The use of `` implicitly enables the functionality of ``. There is usually no need to include the `` element when using ``. -On JDK 9's module path (Jigsaw), Spring's classpath scanning generally works as expected. +On JDK 9's module path (Jigsaw), Infra classpath scanning generally works as expected. However, make sure that your component classes are exported in your `module-info` descriptors. If you expect Spring to invoke non-public members of your classes, make sure that they are 'opened' (that is, that they use an `opens` declaration instead of an @@ -417,7 +417,7 @@ a direct call to another `@Bean` method has standard Java semantics, resulting in an independent instance being returned straight from the factory method itself. The Java language visibility of `@Bean` methods does not have an immediate impact on -the resulting bean definition in Spring's container. You can freely declare your +the resulting bean definition in Infra container. You can freely declare your factory methods as you see fit in non-`@Configuration` classes and also for static methods anywhere. However, regular `@Bean` methods in `@Configuration` classes need to be overridable -- that is, they must not be declared as `private` or `final`. @@ -543,7 +543,7 @@ hierarchies at the class level are irrelevant for metadata purposes. For details on web-specific scopes such as "`request`" or "`session`" in a Spring context, see xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other[Request, Session, Application, and WebSocket Scopes]. As with the pre-built annotations for those scopes, -you may also compose your own scoping annotations by using Spring's meta-annotation +you may also compose your own scoping annotations by using Infra meta-annotation approach: for example, a custom annotation meta-annotated with `@Scope("prototype")`, possibly also declaring a custom scoped-proxy mode. diff --git a/infra-docs/modules/ROOT/pages/core/beans/context-introduction.adoc b/infra-docs/modules/ROOT/pages/core/beans/context-introduction.adoc index d7596e5da8..d3f84230fa 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/context-introduction.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/context-introduction.adoc @@ -177,7 +177,7 @@ The resulting output from the invocation of the `execute()` method is as follows The userDao argument is required. ---- -With regard to internationalization ("`i18n`"), Spring's various `MessageSource` +With regard to internationalization ("`i18n`"), Infra various `MessageSource` implementations follow the same locale resolution and fallback rules as the standard JDK `ResourceBundle`. In short, and continuing with the example `messageSource` defined previously, if you want to resolve messages against the British (`en-GB`) locale, you @@ -222,7 +222,7 @@ You can also use the `MessageSourceAware` interface to acquire a reference to an `ApplicationContext` that implements the `MessageSourceAware` interface is injected with the application context's `MessageSource` when the bean is created and configured. -NOTE: Because Spring's `MessageSource` is based on Java's `ResourceBundle`, it does not merge +NOTE: Because Infra `MessageSource` is based on Java's `ResourceBundle`, it does not merge bundles with the same base name, but will only use the first bundle found. Subsequent message bundles with the same base name are ignored. @@ -293,7 +293,7 @@ The following table describes the standard events that Spring provides: | `RequestHandledEvent` | A web-specific event telling all beans that an HTTP request has been serviced. This event is published after the request is complete. This event is only applicable to - web applications that use Spring's `DispatcherServlet`. + web applications that use Infra `DispatcherServlet`. | `ServletRequestHandledEvent` | A subclass of `RequestHandledEvent` that adds Servlet-specific context information. @@ -301,7 +301,7 @@ The following table describes the standard events that Spring provides: |=== You can also create and publish your own custom events. The following example shows a -simple class that extends Spring's `ApplicationEvent` base class: +simple class that extends Infra `ApplicationEvent` base class: [tabs] ====== @@ -401,7 +401,7 @@ This means that the `publishEvent()` method blocks until all listeners have fini 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, -see the javadoc for Spring's {today-framework-api}/context/event/ApplicationEventMulticaster.html[`ApplicationEventMulticaster`] interface +see the javadoc for Infra {today-framework-api}/context/event/ApplicationEventMulticaster.html[`ApplicationEventMulticaster`] interface and {today-framework-api}/context/event/SimpleApplicationEventMulticaster.html[`SimpleApplicationEventMulticaster`] implementation for configuration options which can be applied to a custom "applicationEventMulticaster" bean definition. In these cases, ThreadLocals and logging context are not propagated for the event processing. @@ -440,7 +440,7 @@ called, if there are any email messages that should be blocked, a custom event o `ApplicationListener` and receives the `BlockedListEvent`, at which point it can notify appropriate parties. -NOTE: Spring's eventing mechanism is designed for simple communication between Spring beans +NOTE: Infra eventing mechanism is designed for simple communication between Spring beans within the same application context. However, for more sophisticated enterprise integration needs, the separately maintained {today-tech-site-projects}/spring-integration/[Infra Integration] project provides @@ -711,7 +711,7 @@ ApplicationEventMulticaster applicationEventMulticaster() { == Convenient Access to Low-level Resources For optimal usage and understanding of application contexts, you should familiarize -yourself with Spring's `Resource` abstraction, as described in Resources. +yourself with Infra `Resource` abstraction, as described in Resources. An application context is a `ResourceLoader`, which can be used to load `Resource` objects. A `Resource` is essentially a more feature rich version of the JDK `java.net.URL` class. @@ -850,9 +850,9 @@ RAR deployment is ideal for application contexts that do not need HTTP entry poi rather consist only of message endpoints and scheduled jobs. Beans in such a context can use application server resources such as the JTA transaction manager and JNDI-bound JDBC `DataSource` instances and JMS `ConnectionFactory` instances and can also register with -the platform's JMX server -- all through Spring's standard transaction management and JNDI +the platform's JMX server -- all through Infra standard transaction management and JNDI and JMX support facilities. Application components can also interact with the application -server's JCA `WorkManager` through Spring's `TaskExecutor` abstraction. +server's JCA `WorkManager` through Infra `TaskExecutor` abstraction. See the javadoc of the {today-framework-api}/jca/context/SpringContextResourceAdapter.html[`SpringContextResourceAdapter`] diff --git a/infra-docs/modules/ROOT/pages/core/beans/context-load-time-weaver.adoc b/infra-docs/modules/ROOT/pages/core/beans/context-load-time-weaver.adoc index 16a1bf8f63..2fd9fc7694 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/context-load-time-weaver.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/context-load-time-weaver.adoc @@ -33,7 +33,7 @@ Alternatively, for XML configuration, you can use the `context:load-time-weaver` Once configured for the `ApplicationContext`, any bean within that `ApplicationContext` may implement `LoadTimeWeaverAware`, thereby receiving a reference to the load-time weaver instance. This is particularly useful in combination with -xref:data-access/orm/jpa.adoc[Spring's JPA support] where load-time weaving may be +xref:data-access/orm/jpa.adoc[Infra JPA support] where load-time weaving may be necessary for JPA class transformation. Consult the {today-framework-api}/orm/jpa/LocalContainerEntityManagerFactoryBean.html[`LocalContainerEntityManagerFactoryBean`] diff --git a/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc b/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc index 829fe815a8..ecd8c0d9f0 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-autowire.adoc @@ -100,7 +100,7 @@ In the latter scenario, you have several options: [[beans-factory-autowire-candidate]] == Excluding a Bean from Autowiring -On a per-bean basis, you can exclude a bean from autowiring. In Spring's XML format, set +On a per-bean basis, you can exclude a bean from autowiring. In Infra XML format, set the `autowire-candidate` attribute of the `` element to `false`. The container makes that specific bean definition unavailable to the autowiring infrastructure (including annotation style configurations such as xref:core/beans/annotation-config/autowired.adoc[`@Autowired`] diff --git a/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-method-injection.adoc b/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-method-injection.adoc index e90d97eda3..06985fec67 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-method-injection.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-method-injection.adoc @@ -207,7 +207,7 @@ public abstract class CommandManager { ====== Note that you should typically declare such annotated lookup methods with a concrete -stub implementation, in order for them to be compatible with Spring's component +stub implementation, in order for them to be compatible with Infra component scanning rules where abstract classes get ignored by default. This limitation does not apply to explicitly registered or explicitly imported bean classes. diff --git a/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-properties-detailed.adoc b/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-properties-detailed.adoc index f32735217f..d40fbb1947 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-properties-detailed.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/dependencies/factory-properties-detailed.adoc @@ -3,7 +3,7 @@ As mentioned in the xref:core/beans/dependencies/factory-collaborators.adoc[previous section], you can define bean properties and constructor arguments as references to other managed beans (collaborators) -or as values defined inline. Spring's XML-based configuration metadata supports +or as values defined inline. Infra XML-based configuration metadata supports sub-element types within its `` and `` elements for this purpose. @@ -12,7 +12,7 @@ purpose. == Straight Values (Primitives, Strings, and so on) The `value` attribute of the `` element specifies a property or constructor -argument as a human-readable string representation. Spring's +argument as a human-readable string representation. Infra xref:core/validation/convert.adoc#core-convert-ConversionService-API[conversion service] is used to convert these values from a `String` to the actual type of the property or argument. The following example shows various values being set: @@ -345,7 +345,7 @@ a parent collection definition is redundant and does not result in the desired m Thanks to Java's support for generic types, you can use strongly typed collections. That is, it is possible to declare a `Collection` type such that it can only contain (for example) `String` elements. If you use Spring to dependency-inject a -strongly-typed `Collection` into a bean, you can take advantage of Spring's +strongly-typed `Collection` into a bean, you can take advantage of Infra type-conversion support such that the elements of your strongly-typed `Collection` instances are converted to the appropriate type prior to being added to the `Collection`. The following Java class and bean definition show how to do so: @@ -385,7 +385,7 @@ public class SomeClass { When the `accounts` property of the `something` bean is prepared for injection, the generics information about the element type of the strongly-typed `Map` is -available by reflection. Thus, Spring's type conversion infrastructure recognizes the +available by reflection. Thus, Infra type conversion infrastructure recognizes the various value elements as being of type `Float`, and the string values (`9.99`, `2.75`, and `3.99`) are converted into an actual `Float` type. diff --git a/infra-docs/modules/ROOT/pages/core/beans/environment.adoc b/infra-docs/modules/ROOT/pages/core/beans/environment.adoc index e50d0fe7c7..4d0ca0b951 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/environment.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/environment.adoc @@ -149,7 +149,7 @@ public class JndiDataConfig { -- NOTE: As mentioned earlier, with `@Bean` methods, you typically choose to use programmatic -JNDI lookups, by using either Spring's `JndiTemplate`/`JndiLocatorDelegate` helpers or the +JNDI lookups, by using either Infra `JndiTemplate`/`JndiLocatorDelegate` helpers or the straight JNDI `InitialContext` usage shown earlier but not the `JndiObjectFactoryBean` variant, which would force you to declare the return type as the `FactoryBean` type. @@ -243,7 +243,7 @@ overloading), a `@Profile` condition needs to be consistently declared on all overloaded methods. If the conditions are inconsistent, only the condition on the first declaration among the overloaded methods matters. Therefore, `@Profile` can not be used to select an overloaded method with a particular argument signature over -another. Resolution between all factory methods for the same bean follows Spring's +another. Resolution between all factory methods for the same bean follows Infra constructor resolution algorithm at creation time. If you want to define alternative beans with different profile conditions, @@ -377,7 +377,7 @@ In addition, you can also declaratively activate profiles through the `infra.profiles.active` property, which may be specified through system environment variables, JVM system properties, servlet context parameters in `web.xml`, or even as an entry in JNDI (see xref:core/beans/environment.adoc#beans-property-source-abstraction[`PropertySource` Abstraction]). In integration tests, active -profiles can be declared by using the `@ActiveProfiles` annotation in the `spring-test` +profiles can be declared by using the `@ActiveProfiles` annotation in the `today-test` module (see xref:testing/testcontext-framework/ctx-management/env-profiles.adoc[context configuration with environment profiles] ). @@ -446,7 +446,7 @@ declaratively, by using the `infra.profiles.default` property. [[beans-property-source-abstraction]] == `PropertySource` Abstraction -Spring's `Environment` abstraction provides search operations over a configurable +Infra `Environment` abstraction provides search operations over a configurable hierarchy of property sources. Consider the following listing: [tabs] @@ -467,7 +467,7 @@ In the preceding snippet, we see a high-level way of asking Spring whether the ` defined for the current environment. To answer this question, the `Environment` object performs a search over a set of {today-framework-api}/core/env/PropertySource.html[`PropertySource`] objects. A `PropertySource` is a simple abstraction over any source of key-value pairs, and -Spring's {today-framework-api}/core/env/StandardEnvironment.html[`StandardEnvironment`] +Infra {today-framework-api}/core/env/StandardEnvironment.html[`StandardEnvironment`] is configured with two PropertySource objects -- one representing the set of JVM system properties (`System.getProperties()`) and one representing the set of system environment variables (`System.getenv()`). @@ -532,7 +532,7 @@ property sources. The {today-framework-api}/context/annotation/PropertySource.html[`@PropertySource`] annotation provides a convenient and declarative mechanism for adding a `PropertySource` -to Spring's `Environment`. +to Infra `Environment`. Given a file called `app.properties` that contains the key-value pair `testbean.name=myTestBean`, the following `@Configuration` class uses `@PropertySource` in such a way that diff --git a/infra-docs/modules/ROOT/pages/core/beans/factory-extension.adoc b/infra-docs/modules/ROOT/pages/core/beans/factory-extension.adoc index facd081178..caf2bcc686 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/factory-extension.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/factory-extension.adoc @@ -217,7 +217,7 @@ cn.taketoday.scripting.groovy.GroovyMessenger@272961 Using callback interfaces or annotations in conjunction with a custom `BeanPostProcessor` implementation is a common means of extending the Infra IoC container. An example is -Spring's `AutowiredAnnotationBeanPostProcessor` -- a `BeanPostProcessor` implementation +Infra `AutowiredAnnotationBeanPostProcessor` -- a `BeanPostProcessor` implementation that ships with the Spring distribution and autowires annotated fields, setter methods, and arbitrary config methods. diff --git a/infra-docs/modules/ROOT/pages/core/beans/factory-nature.adoc b/infra-docs/modules/ROOT/pages/core/beans/factory-nature.adoc index b26320fac6..56fc65b763 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/factory-nature.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/factory-nature.adoc @@ -473,12 +473,12 @@ automatically for a standard context implementation). The `phase` value and any [NOTE] ==== -This section applies only to non-web applications. Spring's web-based +This section applies only to non-web applications. Infra web-based `ApplicationContext` implementations already have code in place to gracefully shut down the Infra IoC container when the relevant web application is shut down. ==== -If you use Spring's IoC container in a non-web application environment (for +If you use Infra IoC container in a non-web application environment (for example, in a rich client desktop environment), register a shutdown hook with the JVM. Doing so ensures a graceful shutdown and calls the relevant destroy methods on your singleton beans so that all resources are released. You must still configure diff --git a/infra-docs/modules/ROOT/pages/core/beans/factory-scopes.adoc b/infra-docs/modules/ROOT/pages/core/beans/factory-scopes.adoc index d75ae37cd4..8da502477e 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/factory-scopes.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/factory-scopes.adoc @@ -69,7 +69,7 @@ return the cached object. The following image shows how the singleton scope work image::singleton.png[] -Spring's concept of a singleton bean differs from the singleton pattern as defined in +Infra concept of a singleton bean differs from the singleton pattern as defined in the Gang of Four (GoF) patterns book. The GoF singleton hard-codes the scope of an object such that one and only one instance of a particular class is created per ClassLoader. The scope of the Spring singleton is best described as being per-container @@ -175,7 +175,7 @@ If you access scoped beans within Spring Web MVC, in effect, within a request th processed by the Spring `DispatcherServlet`, no special setup is necessary. `DispatcherServlet` already exposes all relevant state. -If you use a Servlet web container, with requests processed outside of Spring's +If you use a Servlet web container, with requests processed outside of Infra `DispatcherServlet` (for example, when using JSF), you need to register the `cn.taketoday.web.context.request.RequestContextListener` `ServletRequestListener`. This can be done programmatically by using the `WebApplicationInitializer` interface. @@ -194,7 +194,7 @@ Alternatively, add the following declaration to your web application's `web.xml` ---- -Alternatively, if there are issues with your listener setup, consider using Spring's +Alternatively, if there are issues with your listener setup, consider using Infra `RequestContextFilter`. The filter mapping depends on the surrounding web application configuration, so you have to change it as appropriate. The following listing shows the filter part of a web application: diff --git a/infra-docs/modules/ROOT/pages/core/beans/java/basic-concepts.adoc b/infra-docs/modules/ROOT/pages/core/beans/java/basic-concepts.adoc index 9921790518..e42686845f 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/java/basic-concepts.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/java/basic-concepts.adoc @@ -1,12 +1,12 @@ [[beans-java-basic-concepts]] = Basic Concepts: `@Bean` and `@Configuration` -The central artifacts in Spring's Java configuration support are +The central artifacts in Infra Java configuration support are `@Configuration`-annotated classes and `@Bean`-annotated methods. The `@Bean` annotation is used to indicate that a method instantiates, configures, and initializes a new object to be managed by the Infra IoC container. For those familiar -with Spring's `` XML configuration, the `@Bean` annotation plays the same role as +with Infra `` XML configuration, the `@Bean` annotation plays the same role as the `` element. You can use `@Bean`-annotated methods with any Spring `@Component`. However, they are most often used with `@Configuration` beans. diff --git a/infra-docs/modules/ROOT/pages/core/beans/java/bean-annotation.adoc b/infra-docs/modules/ROOT/pages/core/beans/java/bean-annotation.adoc index 8db04a9c7f..134e38b604 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/java/bean-annotation.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/java/bean-annotation.adoc @@ -237,7 +237,7 @@ public DataSource dataSource() throws NamingException { ====== Also, with `@Bean` methods, you typically use programmatic JNDI lookups, either by -using Spring's `JndiTemplate` or `JndiLocatorDelegate` helpers or straight JNDI +using Infra `JndiTemplate` or `JndiLocatorDelegate` helpers or straight JNDI `InitialContext` usage but not the `JndiObjectFactoryBean` variant (which would force you to declare the return type as the `FactoryBean` type instead of the actual target type, making it harder to use for cross-reference calls in other `@Bean` methods that diff --git a/infra-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc b/infra-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc index 213f6b9469..ce6c6a4dbf 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/java/composing-configuration-classes.adoc @@ -1,7 +1,7 @@ [[beans-java-composing-configuration-classes]] = Composing Java-based Configurations -Spring's Java-based configuration feature lets you compose annotations, which can reduce +Infra Java-based configuration feature lets you compose annotations, which can reduce the complexity of your configuration. @@ -144,7 +144,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 (e.g. in Infra App 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 @@ -409,7 +409,7 @@ javadoc for more detail. [[beans-java-combining]] == Combining Java and XML Configuration -Spring's `@Configuration` class support does not aim to be a 100% complete replacement +Infra `@Configuration` class support does not aim to be a 100% complete replacement for Spring XML. Some facilities, such as Spring XML namespaces, remain an ideal way to configure the container. In cases where XML is convenient or necessary, you have a choice: either instantiate the container in an "`XML-centric`" way by using, for example, diff --git a/infra-docs/modules/ROOT/pages/core/beans/java/instantiating-container.adoc b/infra-docs/modules/ROOT/pages/core/beans/java/instantiating-container.adoc index 866e010160..0e115ed454 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/java/instantiating-container.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/java/instantiating-container.adoc @@ -1,7 +1,7 @@ [[beans-java-instantiating-container]] = Instantiating the Spring Container by Using `AnnotationConfigApplicationContext` -The following sections document Spring's `AnnotationConfigApplicationContext`, introduced in Spring +The following sections document Infra `AnnotationConfigApplicationContext`, introduced in Spring 3.0. This versatile `ApplicationContext` implementation is capable of accepting not only `@Configuration` classes as input but also plain `@Component` classes and classes annotated with JSR-330 metadata. @@ -113,7 +113,7 @@ public class AppConfig { [TIP] ===== Experienced Spring users may be familiar with the XML declaration equivalent from -Spring's `context:` namespace, shown in the following example: +Infra `context:` namespace, shown in the following example: [source,xml,indent=0,subs="verbatim,quotes"] ---- diff --git a/infra-docs/modules/ROOT/pages/core/beans/standard-annotations.adoc b/infra-docs/modules/ROOT/pages/core/beans/standard-annotations.adoc index 70dbb6215e..fac1bd3b8e 100644 --- a/infra-docs/modules/ROOT/pages/core/beans/standard-annotations.adoc +++ b/infra-docs/modules/ROOT/pages/core/beans/standard-annotations.adoc @@ -227,7 +227,7 @@ public class AppConfig { ====== NOTE: In contrast to `@Component`, the JSR-330 `@Named` and the JSR-250 `@ManagedBean` -annotations are not composable. You should use Spring's stereotype model for building +annotations are not composable. You should use Infra stereotype model for building custom component annotations. @@ -253,17 +253,17 @@ features are not available, as the following table shows: | @Scope("singleton") | @Singleton -| The JSR-330 default scope is like Spring's `prototype`. However, in order to keep it - consistent with Spring's general defaults, a JSR-330 bean declared in the Spring +| The JSR-330 default scope is like Infra `prototype`. However, in order to keep it + consistent with Infra general defaults, a JSR-330 bean declared in the Spring container is a `singleton` by default. In order to use a scope other than `singleton`, - you should use Spring's `@Scope` annotation. `jakarta.inject` also provides a + you should use Infra `@Scope` annotation. `jakarta.inject` also provides a `jakarta.inject.Scope` annotation: however, this one is only intended to be used for creating custom annotations. | @Qualifier | @Qualifier / @Named | `jakarta.inject.Qualifier` is just a meta-annotation for building custom qualifiers. - Concrete `String` qualifiers (like Spring's `@Qualifier` with a value) can be associated + Concrete `String` qualifiers (like Infra `@Qualifier` with a value) can be associated through `jakarta.inject.Named`. | @Value @@ -276,9 +276,9 @@ features are not available, as the following table shows: | ObjectFactory | Provider -| `jakarta.inject.Provider` is a direct alternative to Spring's `ObjectFactory`, +| `jakarta.inject.Provider` is a direct alternative to Infra `ObjectFactory`, only with a shorter `get()` method name. It can also be used in combination with - Spring's `@Autowired` or with non-annotated constructors and setter methods. + Infra `@Autowired` or with non-annotated constructors and setter methods. |=== diff --git a/infra-docs/modules/ROOT/pages/core/null-safety.adoc b/infra-docs/modules/ROOT/pages/core/null-safety.adoc index 33847befc9..ce84401589 100644 --- a/infra-docs/modules/ROOT/pages/core/null-safety.adoc +++ b/infra-docs/modules/ROOT/pages/core/null-safety.adoc @@ -48,6 +48,6 @@ like IDEA or Kotlin provide null-safety support in a generic way, without having hard-code support for Spring annotations. It is neither necessary nor recommended to add a JSR-305 dependency to the project classpath to -take advantage of Spring's null-safe APIs. Only projects such as Spring-based libraries that use +take advantage of Infra null-safe APIs. Only projects such as Spring-based libraries that use null-safety annotations in their codebase should add `com.google.code.findbugs:jsr305:3.0.2` with `compileOnly` Gradle configuration or Maven `provided` scope to avoid compiler warnings. diff --git a/infra-docs/modules/ROOT/pages/core/resources.adoc b/infra-docs/modules/ROOT/pages/core/resources.adoc index 35fd2019fd..08ec5b86ea 100644 --- a/infra-docs/modules/ROOT/pages/core/resources.adoc +++ b/infra-docs/modules/ROOT/pages/core/resources.adoc @@ -34,7 +34,7 @@ such as a method to check for the existence of the resource being pointed to. [[resources-resource]] == The `Resource` Interface -Spring's `Resource` interface located in the `cn.taketoday.core.io.` package is +Infra `Resource` interface located in the `cn.taketoday.core.io.` package is meant to be a more capable interface for abstracting access to low-level resources. The following listing provides an overview of the `Resource` interface. See the {today-framework-api}/core/io/Resource.html[`Resource`] javadoc for further details. @@ -192,7 +192,7 @@ creates a `ClassPathResource` in that case. === `FileSystemResource` This is a `Resource` implementation for `java.io.File` handles. It also supports -`java.nio.file.Path` handles, applying Spring's standard String-based path +`java.nio.file.Path` handles, applying Infra standard String-based path transformations but performing all operations via the `java.nio.file.Files` API. For pure `java.nio.path.Path` based support use a `PathResource` instead. `FileSystemResource` supports resolution as a `File` and as a `URL`. @@ -397,7 +397,7 @@ populating `Resource[]` bean properties. `PathMatchingPatternResourceLoader` is resolve a specified resource location path into one or more matching `Resource` objects. The source path may be a simple path which has a one-to-one mapping to a target `Resource`, or alternatively may contain the special `classpath*:` prefix and/or internal -Ant-style regular expressions (matched using Spring's +Ant-style regular expressions (matched using Infra `cn.taketoday.util.AntPathMatcher` utility). Both of the latter are effectively wildcards. @@ -705,7 +705,7 @@ javadoc for details on the various constructors. The resource paths in application context constructor values may be simple paths (as shown earlier), each of which has a one-to-one mapping to a target `Resource` or, alternately, may contain the special `classpath*:` prefix or internal Ant-style patterns -(matched by using Spring's `PathMatcher` utility). Both of the latter are effectively +(matched by using Infra `PathMatcher` utility). Both of the latter are effectively wildcards. One use for this mechanism is when you need to do component-style application assembly. All @@ -815,7 +815,7 @@ target files reside in the file system. This means that a pattern such as `classpath*:*.xml` might not retrieve files from the root of jar files but rather only from the root of expanded directories. -Spring's ability to retrieve classpath entries originates from the JDK's +Infra ability to retrieve classpath entries originates from the JDK's `ClassLoader.getResources()` method, which only returns file system locations for an empty string (indicating potential roots to search). Spring evaluates `URLClassLoader` runtime configuration and the `java.class.path` manifest in jar files @@ -829,7 +829,7 @@ switch of the JAR task. Also, classpath directories may not get exposed based on policies in some environments -- for example, stand-alone applications on JDK 1.7.0_45 and higher (which requires 'Trusted-Library' to be set up in your manifests. -On JDK 9's module path (Jigsaw), Spring's classpath scanning generally works as expected. +On JDK 9's module path (Jigsaw), Infra classpath scanning generally works as expected. Putting resources into a dedicated directory is highly recommendable here as well, avoiding the aforementioned portability problems with searching the jar file root level. ==== diff --git a/infra-docs/modules/ROOT/pages/core/spring-jcl.adoc b/infra-docs/modules/ROOT/pages/core/spring-jcl.adoc index 5fe608bda8..05f620a6c2 100644 --- a/infra-docs/modules/ROOT/pages/core/spring-jcl.adoc +++ b/infra-docs/modules/ROOT/pages/core/spring-jcl.adoc @@ -14,7 +14,7 @@ Boot Logging Reference Documentation]. [NOTE] ==== -Spring's Commons Logging variant is only meant to be used for infrastructure logging +Infra Commons Logging variant is only meant to be used for infrastructure logging purposes in the core framework and in extensions. For logging needs within application code, prefer direct use of Log4j 2.x, SLF4J, or JUL. diff --git a/infra-docs/modules/ROOT/pages/core/validation.adoc b/infra-docs/modules/ROOT/pages/core/validation.adoc index 9441a3ad53..7518e02fd5 100644 --- a/infra-docs/modules/ROOT/pages/core/validation.adoc +++ b/infra-docs/modules/ROOT/pages/core/validation.adoc @@ -20,16 +20,16 @@ this is reference documentation, however, we feel that some explanation might be order. We explain the `BeanWrapper` in this chapter, since, if you are going to use it at all, you are most likely do so when trying to bind data to objects. -Spring's `DataBinder` and the lower-level `BeanWrapper` both use `PropertyEditorSupport` +Infra `DataBinder` and the lower-level `BeanWrapper` both use `PropertyEditorSupport` implementations to parse and format property values. The `PropertyEditor` and `PropertyEditorSupport` types are part of the JavaBeans specification and are also -explained in this chapter. Spring's `core.convert` package provides a general type +explained in this chapter. Infra `core.convert` package provides a general type conversion facility, as well as a higher-level `format` package for formatting UI field values. You can use these packages as simpler alternatives to `PropertyEditorSupport` implementations. They are also discussed in this chapter. Spring supports Java Bean Validation through setup infrastructure and an adaptor to -Spring's own `Validator` contract. Applications can enable Bean Validation once globally, +Infra own `Validator` contract. Applications can enable Bean Validation once globally, as described in xref:core/validation/beanvalidation.adoc[Java Bean Validation], and use it exclusively for all validation needs. In the web layer, applications can further register controller-local Spring `Validator` instances per `DataBinder`, as described in xref:core/validation/beanvalidation.adoc#validation-binder[Configuring a `DataBinder`], which can diff --git a/infra-docs/modules/ROOT/pages/core/validation/beans-beans.adoc b/infra-docs/modules/ROOT/pages/core/validation/beans-beans.adoc index 29ea220708..6bf6b575e5 100644 --- a/infra-docs/modules/ROOT/pages/core/validation/beans-beans.adoc +++ b/infra-docs/modules/ROOT/pages/core/validation/beans-beans.adoc @@ -218,7 +218,7 @@ A couple of examples where property editing is used in Spring: When you use `String` as the value of a property of some bean that you declare in an XML file, Spring (if the setter of the corresponding property has a `Class` parameter) uses `ClassEditor` to try to resolve the parameter to a `Class` object. -* Parsing HTTP request parameters in Spring's MVC framework is done by using all kinds +* Parsing HTTP request parameters in Infra MVC framework is done by using all kinds of `PropertyEditor` implementations that you can manually bind in all subclasses of the `CommandController`. @@ -537,7 +537,7 @@ of our `CustomPropertyEditorRegistrar` into it: ---- Finally (and in a bit of a departure from the focus of this chapter) for those of you -using xref:web/webmvc.adoc#mvc[Spring's MVC web framework], using a `PropertyEditorRegistrar` in +using xref:web/webmvc.adoc#mvc[Infra MVC web framework], using a `PropertyEditorRegistrar` in conjunction with data-binding web controllers can be very convenient. The following example uses a `PropertyEditorRegistrar` in the implementation of an `@InitBinder` method: diff --git a/infra-docs/modules/ROOT/pages/core/validation/beanvalidation.adoc b/infra-docs/modules/ROOT/pages/core/validation/beanvalidation.adoc index fd4dabc44f..0f97caa107 100644 --- a/infra-docs/modules/ROOT/pages/core/validation/beanvalidation.adoc +++ b/infra-docs/modules/ROOT/pages/core/validation/beanvalidation.adoc @@ -255,7 +255,7 @@ XML:: ====== To be eligible for Spring-driven method validation, target classes need to be annotated -with Spring's `@Validated` annotation, which can optionally also declare the validation +with Infra `@Validated` annotation, which can optionally also declare the validation groups to use. See {today-framework-api}/validation/beanvalidation/MethodValidationPostProcessor.html[`MethodValidationPostProcessor`] for setup details with the Hibernate Validator and Bean Validation providers. diff --git a/infra-docs/modules/ROOT/pages/core/validation/format.adoc b/infra-docs/modules/ROOT/pages/core/validation/format.adoc index 31f2bbc6f4..5135802dbf 100644 --- a/infra-docs/modules/ROOT/pages/core/validation/format.adoc +++ b/infra-docs/modules/ROOT/pages/core/validation/format.adoc @@ -249,7 +249,7 @@ The `FormatterRegistry` is an SPI for registering formatters and converters. most environments. You can programmatically or declaratively configure this variant as a Spring bean, e.g. 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). +for use with Infra `DataBinder` and the Spring Expression Language (SpEL). The following listing shows the `FormatterRegistry` SPI: diff --git a/infra-docs/modules/ROOT/pages/core/validation/validator.adoc b/infra-docs/modules/ROOT/pages/core/validation/validator.adoc index e330db63c6..d45cd24540 100644 --- a/infra-docs/modules/ROOT/pages/core/validation/validator.adoc +++ b/infra-docs/modules/ROOT/pages/core/validation/validator.adoc @@ -1,5 +1,5 @@ [[validator]] -= Validation by Using Spring's Validator Interface += Validation by Using Infra Validator Interface Spring features a `Validator` interface that you can use to validate objects. The `Validator` interface works by using an `Errors` object so that, while validating, diff --git a/infra-docs/modules/ROOT/pages/data-access.adoc b/infra-docs/modules/ROOT/pages/data-access.adoc index b96efec082..2abc62071e 100644 --- a/infra-docs/modules/ROOT/pages/data-access.adoc +++ b/infra-docs/modules/ROOT/pages/data-access.adoc @@ -1,13 +1,13 @@ -[[spring-data-tier]] +[[today-data-tier]] = 数据存取 :page-section-summary-toc: 1 This part of the reference documentation is concerned with data access and the interaction between the data access layer and the business or service layer. -Spring's comprehensive transaction management support is covered in some detail, +Infra comprehensive transaction management support is covered in some detail, followed by thorough coverage of the various data access frameworks and technologies -with which the Spring Framework integrates. +with which the TODAY Framework integrates. diff --git a/infra-docs/modules/ROOT/pages/data-access/appendix.adoc b/infra-docs/modules/ROOT/pages/data-access/appendix.adoc index 78e363661b..e05834debf 100644 --- a/infra-docs/modules/ROOT/pages/data-access/appendix.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/appendix.adoc @@ -17,12 +17,12 @@ This part of the appendix lists XML schemas for data access, including the follo [[xsd-schemas-tx]] === The `tx` Schema -The `tx` tags deal with configuring all of those beans in Spring's comprehensive support +The `tx` tags deal with configuring all of those beans in Infra comprehensive support for transactions. These tags are covered in the chapter entitled xref:data-access/transaction.adoc[Transaction Management]. TIP: We strongly encourage you to look at the `'spring-tx.xsd'` file that ships with the -Spring distribution. This file contains the XML Schema for Spring's transaction +Spring distribution. This file contains the XML Schema for Infra transaction configuration and covers all of the various elements in the `tx` namespace, including attribute defaults and similar information. This file is documented inline, and, thus, the information is not repeated here in the interests of adhering to the DRY (Don't diff --git a/infra-docs/modules/ROOT/pages/data-access/dao.adoc b/infra-docs/modules/ROOT/pages/data-access/dao.adoc index c670a56a2a..de2b2d7944 100644 --- a/infra-docs/modules/ROOT/pages/data-access/dao.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/dao.adoc @@ -26,7 +26,7 @@ JDBC exceptions (including database-specific dialects) are also converted to the hierarchy, meaning that you can perform some operations with JDBC within a consistent programming model. -The preceding discussion holds true for the various template classes in Spring's support +The preceding discussion holds true for the various template classes in Infra support for various ORM frameworks. If you use the interceptor-based classes, the application must care about handling `HibernateExceptions` and `PersistenceExceptions` itself, preferably by delegating to the `convertHibernateAccessException(..)` or `convertJpaAccessException(..)` diff --git a/infra-docs/modules/ROOT/pages/data-access/jdbc.adoc b/infra-docs/modules/ROOT/pages/data-access/jdbc.adoc index 0f82cea1b6..18139ca8fc 100644 --- a/infra-docs/modules/ROOT/pages/data-access/jdbc.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/jdbc.adoc @@ -1,7 +1,7 @@ [[jdbc]] = Data Access with JDBC -The value provided by the Spring Framework JDBC abstraction is perhaps best shown by +The value provided by the TODAY Framework JDBC abstraction is perhaps best shown by the sequence of actions outlined in the following table below. The table shows which actions Spring takes care of and which actions are your responsibility. @@ -51,7 +51,7 @@ takes care of and which actions are your responsibility. | |=== -The Spring Framework takes care of all the low-level details that can make JDBC such a +The TODAY Framework takes care of all the low-level details that can make JDBC such a tedious API. diff --git a/infra-docs/modules/ROOT/pages/data-access/jdbc/connections.adoc b/infra-docs/modules/ROOT/pages/data-access/jdbc/connections.adoc index 42091bf8f9..b43c7a0b2e 100644 --- a/infra-docs/modules/ROOT/pages/data-access/jdbc/connections.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/jdbc/connections.adoc @@ -24,7 +24,7 @@ connect to the database. That is the responsibility of the administrator who set the datasource. You most likely fill both roles as you develop and test code, but you do not necessarily have to know how the production data source is configured. -When you use Spring's JDBC layer, you can obtain a data source from JNDI, or you can +When you use Infra JDBC layer, you can obtain a data source from JNDI, or you can configure your own with a connection pool implementation provided by a third party. Traditional choices are Apache Commons DBCP and C3P0 with bean-style `DataSource` classes; for a modern JDBC connection pool, consider HikariCP with its builder-style API instead. @@ -33,7 +33,7 @@ NOTE: You should use the `DriverManagerDataSource` and `SimpleDriverDataSource` (as included in the Spring distribution) only for testing purposes! Those variants do not provide pooling and perform poorly when multiple requests for a connection are made. -The following section uses Spring's `DriverManagerDataSource` implementation. +The following section uses Infra `DriverManagerDataSource` implementation. Several other `DataSource` variants are covered later. To configure a `DriverManagerDataSource`: @@ -135,7 +135,7 @@ operation. This usage is efficient when you know that you need to reuse a connec [[jdbc-AbstractDataSource]] == Extending `AbstractDataSource` -`AbstractDataSource` is an `abstract` base class for Spring's `DataSource` +`AbstractDataSource` is an `abstract` base class for Infra `DataSource` implementations. It implements code that is common to all `DataSource` implementations. You should extend the `AbstractDataSource` class if you write your own `DataSource` implementation. diff --git a/infra-docs/modules/ROOT/pages/data-access/jdbc/core.adoc b/infra-docs/modules/ROOT/pages/data-access/jdbc/core.adoc index 9846474a6c..4b85dd77e2 100644 --- a/infra-docs/modules/ROOT/pages/data-access/jdbc/core.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/jdbc/core.adoc @@ -357,7 +357,7 @@ public class JdbcCorporateEventRepositoryConfiguration { } ---- -If you use Spring's `JdbcDaoSupport` class and your various JDBC-backed DAO classes +If you use Infra `JdbcDaoSupport` class and your various JDBC-backed DAO classes extend from it, your sub-class inherits a `setDataSource(..)` method from the `JdbcDaoSupport` class. You can choose whether to inherit from this class. The `JdbcDaoSupport` class is provided as a convenience only. @@ -627,7 +627,7 @@ also with `JdbcTemplate` and `NamedParameterJdbcTemplate` themselves. NOTE: `JdbcClient` is a flexible but simplified facade for JDBC query/update statements. Advanced capabilities such as batch inserts and stored procedure calls typically require -extra customization: consider Spring's `SimpleJdbcInsert` and `SimpleJdbcCall` classes or +extra customization: consider Infra `SimpleJdbcInsert` and `SimpleJdbcCall` classes or plain direct `JdbcTemplate` usage for any such capabilities not available in `JdbcClient`. @@ -635,7 +635,7 @@ plain direct `JdbcTemplate` usage for any such capabilities not available in `Jd == Using `SQLExceptionTranslator` `SQLExceptionTranslator` is an interface to be implemented by classes that can translate -between ``SQLException``s and Spring's own `cn.taketoday.dao.DataAccessException`, +between ``SQLException``s and Infra own `cn.taketoday.dao.DataAccessException`, which is agnostic in regard to data access strategy. Implementations can be generic (for example, using SQLState codes for JDBC) or proprietary (for example, using Oracle error codes) for greater precision. This exception translation mechanism is used behind the diff --git a/infra-docs/modules/ROOT/pages/data-access/jdbc/embedded-database-support.adoc b/infra-docs/modules/ROOT/pages/data-access/jdbc/embedded-database-support.adoc index 628b8bf1da..7cb96bdf1c 100644 --- a/infra-docs/modules/ROOT/pages/data-access/jdbc/embedded-database-support.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/jdbc/embedded-database-support.adoc @@ -182,7 +182,7 @@ process) -- for example, integration tests against embedded databases whose `ApplicationContext` configuration differs only with regard to which bean definition profiles are active. -The root cause of such errors is the fact that Spring's `EmbeddedDatabaseFactory` (used +The root cause of such errors is the fact that Infra `EmbeddedDatabaseFactory` (used internally by both the `` XML namespace element and the `EmbeddedDatabaseBuilder` for Java configuration) sets the name of the embedded database to `testdb` if not otherwise specified. For the case of ``, the @@ -192,7 +192,7 @@ do not result in a new database. Instead, the same JDBC connection URL is reused and attempts to create a new embedded database actually point to an existing embedded database created from the same configuration. -To address this common issue, Spring Framework 4.2 provides support for generating +To address this common issue, TODAY Framework 4.2 provides support for generating unique names for embedded databases. To enable the use of generated names, use one of the following options. diff --git a/infra-docs/modules/ROOT/pages/data-access/jdbc/packages.adoc b/infra-docs/modules/ROOT/pages/data-access/jdbc/packages.adoc index 0c3716fbd5..098bfac346 100644 --- a/infra-docs/modules/ROOT/pages/data-access/jdbc/packages.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/jdbc/packages.adoc @@ -1,7 +1,7 @@ [[jdbc-packages]] = Package Hierarchy -The Spring Framework's JDBC abstraction framework consists of four different packages: +The TODAY Framework's JDBC abstraction framework consists of four different packages: * `core`: The `cn.taketoday.jdbc.core` package contains the `JdbcTemplate` class and its various callback interfaces, plus a variety of related classes. A subpackage diff --git a/infra-docs/modules/ROOT/pages/data-access/jdbc/parameter-handling.adoc b/infra-docs/modules/ROOT/pages/data-access/jdbc/parameter-handling.adoc index 2c7dd49f74..fc92a77279 100644 --- a/infra-docs/modules/ROOT/pages/data-access/jdbc/parameter-handling.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/jdbc/parameter-handling.adoc @@ -2,7 +2,7 @@ = Common Problems with Parameter and Data Value Handling Common problems with parameters and data values exist in the different approaches -provided by Spring Framework's JDBC support. This section covers how to address them. +provided by TODAY Framework's JDBC support. This section covers how to address them. [[jdbc-type-information]] diff --git a/infra-docs/modules/ROOT/pages/data-access/orm/general.adoc b/infra-docs/modules/ROOT/pages/data-access/orm/general.adoc index b20d9c4bcc..f55917ef4d 100644 --- a/infra-docs/modules/ROOT/pages/data-access/orm/general.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/orm/general.adoc @@ -5,13 +5,13 @@ This section highlights considerations that apply to all ORM technologies. The xref:data-access/orm/hibernate.adoc[Hibernate] section provides more details and also show these features and configurations in a concrete context. -The major goal of Spring's ORM integration is clear application layering (with any data +The major goal of Infra ORM integration is clear application layering (with any data access and transaction technology) and for loose coupling of application objects -- no more business service dependencies on the data access or transaction strategy, no more hard-coded resource lookups, no more hard-to-replace singletons, no more custom service registries. The goal is to have one simple and consistent approach to wiring up application objects, keeping them as reusable and free from container dependencies as possible. All the individual -data access features are usable on their own but integrate nicely with Spring's +data access features are usable on their own but integrate nicely with Infra application context concept, providing XML-based configuration and cross-referencing of plain JavaBean instances that need not be Spring-aware. In a typical Spring application, many important objects are JavaBeans: data access templates, data access objects, @@ -95,7 +95,7 @@ appropriate translation on the thrown exceptions. In summary, you can implement DAOs based on the plain persistence technology's API and annotations while still benefiting from Spring-managed transactions, dependency -injection, and transparent exception conversion (if desired) to Spring's custom +injection, and transparent exception conversion (if desired) to Infra custom exception hierarchies. diff --git a/infra-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc b/infra-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc index 7fb1c8e912..acf6b062c7 100644 --- a/infra-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/orm/hibernate.adoc @@ -10,7 +10,7 @@ cover the other ORM technologies and show brief examples. [NOTE] ==== -As of Spring Framework 6.0, Spring requires Hibernate ORM 5.5+ for Spring's +As of TODAY Framework 6.0, Spring requires Hibernate ORM 5.5+ for Infra `HibernateJpaVendorAdapter` as well as for a native Hibernate `SessionFactory` setup. We recommend Hibernate ORM 5.6 as the last feature branch in that Hibernate generation. @@ -71,7 +71,7 @@ configuration, as the following example shows: ---- -You can also access a JNDI-located `SessionFactory`, using Spring's +You can also access a JNDI-located `SessionFactory`, using Infra `JndiObjectFactoryBean` / `` to retrieve and expose it. However, that is typically not common outside of an EJB context. @@ -87,7 +87,7 @@ On `LocalSessionFactoryBean`, this is available through the `bootstrapExecutor` property. On the programmatic `LocalSessionFactoryBuilder`, there is an overloaded `buildSessionFactory` method that takes a bootstrap executor argument. -As of Spring Framework 5.1, such a native Hibernate setup can also expose a JPA +As of TODAY Framework 5.1, such a native Hibernate setup can also expose a JPA `EntityManagerFactory` for standard JPA interaction next to native Hibernate access. See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate Setup for JPA] for details. ==== @@ -97,7 +97,7 @@ See xref:data-access/orm/jpa.adoc#orm-jpa-hibernate[Native Hibernate Setup for J == Implementing DAOs Based on the Plain Hibernate API Hibernate has a feature called contextual sessions, wherein Hibernate itself manages -one current `Session` per transaction. This is roughly equivalent to Spring's +one current `Session` per transaction. This is roughly equivalent to Infra synchronization of one Hibernate `Session` per transaction. A corresponding DAO implementation resembles the following example, based on the plain Hibernate API: @@ -133,7 +133,7 @@ Hibernate's CaveatEmptor sample application. (In general, do not keep any resour `static` variables unless absolutely necessary.) The preceding DAO example follows the dependency injection pattern. It fits nicely into a Infra IoC -container, as it would if coded against Spring's `HibernateTemplate`. +container, as it would if coded against Infra `HibernateTemplate`. You can also set up such a DAO in plain Java (for example, in unit tests). To do so, instantiate it and call `setSessionFactory(..)` with the desired factory reference. As a Spring bean definition, the DAO would resemble the following: @@ -161,12 +161,12 @@ tying the caller to the implementation strategy. This trade off might be accepta applications that are strongly Hibernate-based, do not need any special exception treatment, or both. -Fortunately, Spring's `LocalSessionFactoryBean` supports Hibernate's +Fortunately, Infra `LocalSessionFactoryBean` supports Hibernate's `SessionFactory.getCurrentSession()` method for any Spring transaction strategy, returning the current Spring-managed transactional `Session`, even with `HibernateTransactionManager`. The standard behavior of that method remains to return the current `Session` associated with the ongoing JTA transaction, if any. -This behavior applies regardless of whether you use Spring's +This behavior applies regardless of whether you use Infra `JtaTransactionManager`, EJB container managed transactions (CMTs), or JTA. In summary, you can implement DAOs based on the plain Hibernate API, while still being @@ -176,7 +176,7 @@ able to participate in Spring-managed transactions. [[orm-hibernate-tx-declarative]] == Declarative Transaction Demarcation -We recommend that you use Spring's declarative transaction support, which lets you +We recommend that you use Infra declarative transaction support, which lets you replace explicit transaction demarcation API calls in your Java code with an AOP transaction interceptor. You can configure this transaction interceptor in a Spring container by using either Java annotations or XML. This declarative transaction capability @@ -314,7 +314,7 @@ public class ProductServiceImpl implements ProductService { ====== -Spring's `TransactionInterceptor` lets any checked application exception be thrown +Infra `TransactionInterceptor` lets any checked application exception be thrown with the callback code, while `TransactionTemplate` is restricted to unchecked exceptions within the callback. `TransactionTemplate` triggers a rollback in case of an unchecked application exception or if the transaction is marked rollback-only by @@ -333,7 +333,7 @@ JTA subsystem of the container) for Hibernate applications. You can even use a c `PlatformTransactionManager` implementation. Switching from native Hibernate transaction management to JTA (such as when facing distributed transaction requirements for certain deployments of your application) is only a matter of configuration. You can replace -the Hibernate transaction manager with Spring's JTA transaction implementation. Both +the Hibernate transaction manager with Infra JTA transaction implementation. Both transaction demarcation and data access code work without changes, because they use the generic transaction management APIs. @@ -378,9 +378,9 @@ benefits. Deploying a `SessionFactory` through Hibernate's JCA connector provide added value of participating in the Jakarta EE server's management infrastructure, but does not add actual value beyond that. -Spring's transaction support is not bound to a container. When configured with any strategy +Infra transaction support is not bound to a container. When configured with any strategy other than JTA, transaction support also works in a stand-alone or test environment. -Especially in the typical case of single-database transactions, Spring's single-resource +Especially in the typical case of single-database transactions, Infra single-resource local transaction support is a lightweight and powerful alternative to JTA. When you use local EJB stateless session beans to drive transactions, you depend both on an EJB container and on JTA, even if you access only a single database and use only stateless @@ -389,14 +389,14 @@ transactions. Direct use of JTA programmatically also requires a Jakarta EE envi Spring-driven transactions can work as well with a locally defined Hibernate `SessionFactory` as they do with a local JDBC `DataSource`, provided they access a -single database. Thus, you need only use Spring's JTA transaction strategy when you +single database. Thus, you need only use Infra JTA transaction strategy when you have distributed transaction requirements. A JCA connector requires container-specific deployment steps, and (obviously) JCA support in the first place. This configuration requires more work than deploying a simple web application with local resource definitions and Spring-driven transactions. All things considered, if you do not use EJBs, stick with local `SessionFactory` setup -and Spring's `HibernateTransactionManager` or `JtaTransactionManager`. You get all of +and Infra `HibernateTransactionManager` or `JtaTransactionManager`. You get all of the benefits, including proper transactional JVM-level caching and distributed transactions, without the inconvenience of container deployment. JNDI registration of a Hibernate `SessionFactory` through the JCA connector adds value only when used in @@ -443,7 +443,7 @@ When Hibernate is not configured with any awareness of the JTA transaction manag the following events occur when a JTA transaction commits: * The JTA transaction commits. -* Spring's `JtaTransactionManager` is synchronized to the JTA transaction, so it is +* Infra `JtaTransactionManager` is synchronized to the JTA transaction, so it is called back through an `afterCompletion` callback by the JTA transaction manager. * Among other activities, this synchronization can trigger a callback by Spring to Hibernate, through Hibernate's `afterTransactionCompletion` callback (used to clear @@ -457,7 +457,7 @@ When Hibernate is configured with awareness of the JTA transaction manager, the following events occur when a JTA transaction commits: * The JTA transaction is ready to commit. -* Spring's `JtaTransactionManager` is synchronized to the JTA transaction, so the +* Infra `JtaTransactionManager` is synchronized to the JTA transaction, so the transaction is called back through a `beforeCompletion` callback by the JTA transaction manager. * Spring is aware that Hibernate itself is synchronized to the JTA transaction and diff --git a/infra-docs/modules/ROOT/pages/data-access/orm/introduction.adoc b/infra-docs/modules/ROOT/pages/data-access/orm/introduction.adoc index f513d917ff..db03b2033c 100644 --- a/infra-docs/modules/ROOT/pages/data-access/orm/introduction.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/orm/introduction.adoc @@ -1,13 +1,13 @@ [[orm-introduction]] = Introduction to ORM with Spring -The Spring Framework supports integration with the Java Persistence API (JPA) and +The TODAY Framework supports integration with the Java Persistence API (JPA) and supports native Hibernate for resource management, data access object (DAO) implementations, and transaction strategies. For example, for Hibernate, there is first-class support with several convenient IoC features that address many typical Hibernate integration issues. You can configure all of the supported features for OR (object relational) mapping -tools through Dependency Injection. They can participate in Spring's resource and -transaction management, and they comply with Spring's generic transaction and DAO +tools through Dependency Injection. They can participate in Infra resource and +transaction management, and they comply with Infra generic transaction and DAO exception hierarchies. The recommended integration style is to code DAOs against plain Hibernate or JPA APIs. @@ -19,9 +19,9 @@ library, regardless of technology, because everything is designed as a set of re JavaBeans. ORM in a Infra IoC container facilitates configuration and deployment. Thus, most examples in this section show configuration inside a Spring container. -The benefits of using the Spring Framework to create your ORM DAOs include: +The benefits of using the TODAY Framework to create your ORM DAOs include: -* *Easier testing.* Spring's IoC approach makes it easy to swap the implementations +* *Easier testing.* Infra IoC approach makes it easy to swap the implementations and configuration locations of Hibernate `SessionFactory` instances, JDBC `DataSource` instances, transaction managers, and mapped object implementations (if needed). This in turn makes it much easier to test each piece of persistence-related code in diff --git a/infra-docs/modules/ROOT/pages/data-access/orm/jpa.adoc b/infra-docs/modules/ROOT/pages/data-access/orm/jpa.adoc index 56452e6af3..10fc1c4776 100644 --- a/infra-docs/modules/ROOT/pages/data-access/orm/jpa.adoc +++ b/infra-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 (e.g. Tomcat's weaving-capable class loader or Infra JVM agent) and automatic propagation of the weaver to all weaver-aware beans: [source,xml,indent=0,subs="verbatim,quotes"] @@ -471,10 +471,10 @@ the persistence units via `@Autowired @Qualifier("...")`. == Spring-driven JPA Transactions NOTE: We strongly encourage you to read xref:data-access/transaction/declarative.adoc[Declarative Transaction Management], -if you have not already done so, to get more detailed coverage of Spring's declarative transaction support. +if you have not already done so, to get more detailed coverage of Infra declarative transaction support. The recommended strategy for JPA is local transactions through JPA's native transaction -support. Spring's `JpaTransactionManager` provides many capabilities known from local +support. Infra `JpaTransactionManager` provides many capabilities known from local JDBC transactions (such as transaction-specific isolation levels and resource-level read-only optimizations) against any regular JDBC connection pool, without requiring a JTA transaction coordinator and XA-capable resources. @@ -503,14 +503,14 @@ features supported by Spring, usually in a vendor-specific manner: * Applying specific transaction semantics (such as custom isolation level or transaction timeout) * Retrieving the transactional JDBC `Connection` (for exposure to JDBC-based DAOs) -* Advanced translation of `PersistenceException` to Spring's `DataAccessException` +* Advanced translation of `PersistenceException` to Infra `DataAccessException` This is particularly valuable for special transaction semantics and for advanced translation of exception. The default implementation (`DefaultJpaDialect`) does not provide any special abilities and, if the features listed earlier are required, you have to specify the appropriate dialect. -TIP: As an even broader provider adaptation facility primarily for Spring's full-featured +TIP: As an even broader provider adaptation facility primarily for Infra full-featured `LocalContainerEntityManagerFactoryBean` setup, `JpaVendorAdapter` combines the capabilities of `JpaDialect` with other provider-specific defaults. Specifying a `HibernateJpaVendorAdapter` or `EclipseLinkJpaVendorAdapter` is the most convenient @@ -520,7 +520,7 @@ Spring-driven transaction management (that is, for use with `JpaTransactionManag See the {today-framework-api}/orm/jpa/JpaDialect.html[`JpaDialect`] and {today-framework-api}/orm/jpa/JpaVendorAdapter.html[`JpaVendorAdapter`] javadoc for -more details of its operations and how they are used within Spring's JPA support. +more details of its operations and how they are used within Infra JPA support. [[orm-jpa-jta]] @@ -528,7 +528,7 @@ more details of its operations and how they are used within Spring's JPA support As an alternative to `JpaTransactionManager`, Spring also allows for multi-resource transaction coordination through JTA, either in a Jakarta EE environment or with a -stand-alone transaction coordinator, such as Atomikos. Aside from choosing Spring's +stand-alone transaction coordinator, such as Atomikos. Aside from choosing Infra `JtaTransactionManager` instead of `JpaTransactionManager`, you need to take few further steps: @@ -543,7 +543,7 @@ provider-specific, typically through special properties to be specified as `jpaP on `LocalContainerEntityManagerFactoryBean`. In the case of Hibernate, these properties are even version-specific. See your Hibernate documentation for details. -* Spring's `HibernateJpaVendorAdapter` enforces certain Spring-oriented defaults, such +* Infra `HibernateJpaVendorAdapter` enforces certain Spring-oriented defaults, such as the connection release mode, `on-close`, which matches Hibernate's own default in Hibernate 5.0 but not any more in Hibernate 5.1+. For a JTA setup, make sure to declare your persistence unit transaction type as "JTA". Alternatively, set Hibernate 5.2's @@ -565,7 +565,7 @@ A native `LocalSessionFactoryBean` setup in combination with `HibernateTransacti allows for interaction with `@PersistenceContext` and other JPA access code. A Hibernate `SessionFactory` natively implements JPA's `EntityManagerFactory` interface now and a Hibernate `Session` handle natively is a JPA `EntityManager`. -Spring's JPA support facilities automatically detect native Hibernate sessions. +Infra JPA support facilities automatically detect native Hibernate sessions. Such native Hibernate setup can, therefore, serve as a replacement for a standard JPA `LocalContainerEntityManagerFactoryBean` and `JpaTransactionManager` combination @@ -575,7 +575,7 @@ the same local transaction. Such a setup also provides stronger Hibernate integr and more configuration flexibility, because it is not constrained by JPA bootstrap contracts. You do not need `HibernateJpaVendorAdapter` configuration in such a scenario, -since Spring's native Hibernate setup provides even more features +since Infra native Hibernate setup provides even more features (for example, custom Hibernate Integrator setup, Hibernate 5.3 bean container integration, and stronger optimizations for read-only transactions). Last but not least, you can also express native Hibernate setup through `LocalSessionFactoryBuilder`, diff --git a/infra-docs/modules/ROOT/pages/data-access/oxm.adoc b/infra-docs/modules/ROOT/pages/data-access/oxm.adoc index 157d3c8f9f..bfe87b5131 100644 --- a/infra-docs/modules/ROOT/pages/data-access/oxm.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/oxm.adoc @@ -6,7 +6,7 @@ [[oxm-introduction]] == Introduction -This chapter, describes Spring's Object-XML Mapping support. Object-XML +This chapter, describes Infra Object-XML Mapping support. Object-XML Mapping (O-X mapping for short) is the act of converting an XML document to and from an object. This conversion process is also known as XML Marshalling, or XML Serialization. This chapter uses these terms interchangeably. @@ -26,7 +26,7 @@ Some of the benefits of using Spring for your O/X mapping needs are: [[oxm-ease-of-configuration]] === Ease of configuration -Spring's bean factory makes it easy to configure marshallers, without needing to +Infra bean factory makes it easy to configure marshallers, without needing to construct JAXB context, JiBX binding factories, and so on. You can configure the marshallers as you would any other bean in your application context. Additionally, XML namespace-based configuration is available for a number of marshallers, making the configuration even @@ -36,7 +36,7 @@ simpler. [[oxm-consistent-interfaces]] === Consistent Interfaces -Spring's O-X mapping operates through two global interfaces: {today-framework-api}/oxm/Marshaller.html[`Marshaller`] and +Infra O-X mapping operates through two global interfaces: {today-framework-api}/oxm/Marshaller.html[`Marshaller`] and {today-framework-api}/oxm/Unmarshaller.html[`Unmarshaller`]. These abstractions let you switch O-X mapping frameworks with relative ease, with little or no change required on the classes that do the marshalling. This approach has the additional benefit of making it possible to do XML @@ -167,7 +167,7 @@ image::oxm-exceptions.png[] [[oxm-usage]] == Using `Marshaller` and `Unmarshaller` -You can use Spring's OXM for a wide variety of situations. In the following example, we +You can use Infra OXM for a wide variety of situations. In the following example, we use it to marshal the settings of a Spring-managed application as an XML file. In the following example, we use a simple JavaBean to represent the settings: @@ -337,7 +337,7 @@ package. [[oxm-jaxb2]] === Using `Jaxb2Marshaller` -The `Jaxb2Marshaller` class implements both of Spring's `Marshaller` and `Unmarshaller` +The `Jaxb2Marshaller` class implements both of Infra `Marshaller` and `Unmarshaller` interfaces. It requires a context path to operate. You can set the context path by setting the `contextPath` property. The context path is a list of colon-separated Java package names that contain schema derived classes. It also offers a `classesToBeBound` property, diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction.adoc index e21a2cd7ac..258ee1155a 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction.adoc @@ -2,7 +2,7 @@ = Transaction Management Comprehensive transaction support is among the most compelling reasons to use the Spring -Framework. The Spring Framework provides a consistent abstraction for transaction +Framework. The TODAY Framework provides a consistent abstraction for transaction management that delivers the following benefits: * A consistent programming model across different transaction APIs, such as Java @@ -10,14 +10,14 @@ management that delivers the following benefits: * Support for xref:data-access/transaction/declarative.adoc[declarative transaction management]. * A simpler API for xref:data-access/transaction/programmatic.adoc[programmatic] transaction management than complex transaction APIs, such as JTA. -* Excellent integration with Spring's data access abstractions. +* Excellent integration with Infra data access abstractions. -The following sections describe the Spring Framework's transaction features and technologies: +The following sections describe the TODAY Framework's transaction features and technologies: -* xref:data-access/transaction/motivation.adoc[Advantages of the Spring Framework's transaction support model] - describes why you would use the Spring Framework's transaction abstraction instead of EJB +* xref:data-access/transaction/motivation.adoc[Advantages of the TODAY Framework's transaction support model] + describes why you would use the TODAY Framework's transaction abstraction instead of EJB Container-Managed Transactions (CMT) or choosing to drive transactions through a proprietary API. -* xref:data-access/transaction/strategies.adoc[Understanding the Spring Framework transaction abstraction] +* xref:data-access/transaction/strategies.adoc[Understanding the TODAY Framework transaction abstraction] outlines the core classes and describes how to configure and obtain `DataSource` instances from a variety of sources. * xref:data-access/transaction/tx-resource-synchronization.adoc[Synchronizing resources with transactions] diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/application-server-integration.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/application-server-integration.adoc index 536c7c8328..bf333bad53 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/application-server-integration.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/application-server-integration.adoc @@ -1,8 +1,8 @@ [[transaction-application-server-integration]] = Application server-specific integration -Spring's transaction abstraction is generally application server-agnostic. Additionally, -Spring's `JtaTransactionManager` class (which can optionally perform a JNDI lookup for +Infra transaction abstraction is generally application server-agnostic. Additionally, +Infra `JtaTransactionManager` class (which can optionally perform a JNDI lookup for the JTA `UserTransaction` and `TransactionManager` objects) autodetects the location for the latter object, which varies by application server. Having access to the JTA `TransactionManager` allows for enhanced transaction semantics -- in particular, @@ -10,7 +10,7 @@ supporting transaction suspension. See the {today-framework-api}/transaction/jta/JtaTransactionManager.html[`JtaTransactionManager`] javadoc for details. -Spring's `JtaTransactionManager` is the standard choice to run on Jakarta EE application +Infra `JtaTransactionManager` is the standard choice to run on Jakarta EE application servers and is known to work on all common servers. Advanced functionality, such as transaction suspension, works on many servers as well (including GlassFish, JBoss and Geronimo) without any special configuration required. diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative.adoc index 78487aa34f..45b637afc4 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative.adoc @@ -1,35 +1,35 @@ [[transaction-declarative]] = Declarative Transaction Management -NOTE: Most Spring Framework users choose declarative transaction management. This option has +NOTE: Most TODAY Framework users choose declarative transaction management. This option has the least impact on application code and, hence, is most consistent with the ideals of a non-invasive lightweight container. -The Spring Framework's declarative transaction management is made possible with Spring +The TODAY Framework's declarative transaction management is made possible with Spring aspect-oriented programming (AOP). However, as the transactional aspects code comes -with the Spring Framework distribution and may be used in a boilerplate fashion, AOP +with the TODAY Framework distribution and may be used in a boilerplate fashion, AOP concepts do not generally have to be understood to make effective use of this code. -The Spring Framework's declarative transaction management is similar to EJB CMT, in that +The TODAY Framework's declarative transaction management is similar to EJB CMT, in that you can specify transaction behavior (or lack of it) down to the individual method level. You can make a `setRollbackOnly()` call within a transaction context, if necessary. The differences between the two types of transaction management are: -* Unlike EJB CMT, which is tied to JTA, the Spring Framework's declarative transaction +* Unlike EJB CMT, which is tied to JTA, the TODAY Framework's declarative transaction management works in any environment. It can work with JTA transactions or local transactions by using JDBC, JPA, or Hibernate by adjusting the configuration files. -* You can apply the Spring Framework declarative transaction management to any class, +* You can apply the TODAY Framework declarative transaction management to any class, not merely special classes such as EJBs. -* The Spring Framework offers declarative +* The TODAY Framework offers declarative xref:data-access/transaction/declarative/rolling-back.adoc[rollback rules], a feature with no EJB equivalent. Both programmatic and declarative support for rollback rules is provided. -* The Spring Framework lets you customize transactional behavior by using AOP. +* The TODAY Framework lets you customize transactional behavior by using AOP. For example, you can insert custom behavior in the case of transaction rollback. You can also add arbitrary advice, along with transactional advice. With EJB CMT, you cannot influence the container's transaction management, except with `setRollbackOnly()`. -* The Spring Framework does not support propagation of transaction contexts across +* The TODAY Framework does not support propagation of transaction contexts across remote calls, as high-end application servers do. If you need this feature, we recommend that you use EJB. However, consider carefully before using such a feature, because, normally, one does not want transactions to span remote calls. diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc index d2657e2df9..25a3765e91 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/annotations.adoc @@ -8,7 +8,7 @@ danger of undue coupling, because code that is meant to be used transactionally almost always deployed that way anyway. NOTE: The standard `jakarta.transaction.Transactional` annotation is also supported as -a drop-in replacement to Spring's own annotation. Please refer to the JTA documentation +a drop-in replacement to Infra own annotation. Please refer to the JTA documentation for more details. The ease-of-use afforded by the use of the `@Transactional` annotation is best @@ -220,10 +220,10 @@ is modified) to support `@Transactional` runtime behavior on any kind of method. | `mode` | `mode` | `proxy` -| The default mode (`proxy`) processes annotated beans to be proxied by using Spring's AOP +| The default mode (`proxy`) processes annotated beans to be proxied by using Infra AOP framework (following proxy semantics, as discussed earlier, applying to method calls coming in through the proxy only). The alternative mode (`aspectj`) instead weaves the - affected classes with Spring's AspectJ transaction aspect, modifying the target class + affected classes with Infra AspectJ transaction aspect, modifying the target class byte code to apply to any kind of method call. AspectJ weaving requires `spring-aspects.jar` in the classpath as well as having load-time weaving (or compile-time weaving) enabled. (See xref:core/aop/using-aspectj.adoc#aop-aj-ltw-spring[Spring configuration] for details @@ -382,7 +382,7 @@ For further customizations, `AnnotationTransactionAttributeSource` provides an Note that transaction-specific rollback rules override the default behavior but retain the chosen default for unspecified exceptions. This is the case for -Spring's `@Transactional` as well as JTA's `jakarta.transaction.Transactional` +Infra `@Transactional` as well as JTA's `jakarta.transaction.Transactional` annotation. Unless you rely on EJB-style business exceptions with commit behavior, it is @@ -483,7 +483,7 @@ to be unique within a set of type-matching beans, not having to serve as an ID. == Custom Composed Annotations If you find you repeatedly use the same attributes with `@Transactional` on many different methods, -xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[Spring's meta-annotation support] +xref:core/beans/classpath-scanning.adoc#beans-meta-annotations[Infra meta-annotation support] lets you define custom composed annotations for your specific use cases. For example, consider the following annotation definitions: diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/aspectj.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/aspectj.adoc index c97f83c6ca..ca4206edc6 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/aspectj.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/aspectj.adoc @@ -1,13 +1,13 @@ [[transaction-declarative-aspectj]] = Using `@Transactional` with AspectJ -You can also use the Spring Framework's `@Transactional` support outside of a Spring +You can also use the TODAY Framework's `@Transactional` support outside of a Spring container by means of an AspectJ aspect. To do so, first annotate your classes (and optionally your classes' methods) with the `@Transactional` annotation, and then link (weave) your application with the `cn.taketoday.transaction.aspectj.AnnotationTransactionAspect` defined in the `spring-aspects.jar` file. You must also configure the aspect with a transaction -manager. You can use the Spring Framework's IoC container to take care of +manager. You can use the TODAY Framework's IoC container to take care of dependency-injecting the aspect. The simplest way to configure the transaction management aspect is to use the `` element and specify the `mode` attribute to `aspectj` as described in xref:data-access/transaction/declarative/annotations.adoc[Using `@Transactional`]. Because @@ -48,7 +48,7 @@ regardless of visibility. To weave your applications with the `AnnotationTransactionAspect`, you must either build your application with AspectJ (see the {aspectj-docs-devguide}/index.html[AspectJ Development -Guide]) or use load-time weaving. See xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time weaving with AspectJ in the Spring Framework] +Guide]) or use load-time weaving. See xref:core/aop/using-aspectj.adoc#aop-aj-ltw[Load-time weaving with AspectJ in the TODAY Framework] for a discussion of load-time weaving with AspectJ. diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/first-example.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/first-example.adoc index ca0c2abada..e6d4775af8 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/first-example.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/first-example.adoc @@ -237,7 +237,7 @@ output and the stack trace from the `UnsupportedOperationException` thrown by th To use reactive transaction management the code has to use reactive types. -NOTE: Spring Framework uses the `ReactiveAdapterRegistry` to determine whether a method +NOTE: TODAY Framework uses the `ReactiveAdapterRegistry` to determine whether a method return type is reactive. The following listing shows a modified version of the previously used `FooService`, but diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc index f65260e597..d55534e608 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/rolling-back.adoc @@ -8,18 +8,18 @@ fashion in XML configuration. For details on controlling rollback semantics decl with the `@Transactional` annotation, see xref:data-access/transaction/declarative/annotations.adoc#transaction-declarative-attransactional-settings[`@Transactional` Settings]. -The recommended way to indicate to the Spring Framework's transaction infrastructure +The recommended way to indicate to the TODAY Framework's transaction infrastructure that a transaction's work is to be rolled back is to throw an `Exception` from code that -is currently executing in the context of a transaction. The Spring Framework's +is currently executing in the context of a transaction. The TODAY Framework's transaction infrastructure code catches any unhandled `Exception` as it bubbles up the call stack and makes a determination whether to mark the transaction for rollback. -In its default configuration, the Spring Framework's transaction infrastructure code +In its default configuration, the TODAY Framework's transaction infrastructure code marks a transaction for rollback only in the case of runtime, unchecked exceptions. That is, when the thrown exception is an instance or subclass of `RuntimeException`. (`Error` instances also, by default, result in a rollback). -As of Spring Framework 5.2, the default configuration also provides support for +As of TODAY Framework 5.2, the default configuration also provides support for Vavr's `Try` method to trigger transaction rollbacks when it returns a 'Failure'. This allows you to handle functional-style errors using Try and have the transaction automatically rolled back in case of a failure. For more information on Vavr's Try, @@ -108,7 +108,7 @@ application-specific `Exception` type by supplying an _exception pattern_ via th ---- If you do not want a transaction rolled back when an exception is thrown, you can also -specify 'no rollback' rules. The following example tells the Spring Framework's +specify 'no rollback' rules. The following example tells the TODAY Framework's transaction infrastructure to commit the attendant transaction even in the face of an unhandled `InstrumentNotFoundException`: @@ -122,7 +122,7 @@ unhandled `InstrumentNotFoundException`: ---- -When the Spring Framework's transaction infrastructure catches an exception and consults +When the TODAY Framework's transaction infrastructure catches an exception and consults the configured rollback rules to determine whether to mark the transaction for rollback, the strongest matching rule wins. So, in the case of the following configuration, any exception other than an `InstrumentNotFoundException` results in a rollback of the @@ -138,7 +138,7 @@ attendant transaction: ---- You can also indicate a required rollback programmatically. Although simple, this process -is quite invasive and tightly couples your code to the Spring Framework's transaction +is quite invasive and tightly couples your code to the TODAY Framework's transaction infrastructure. The following example shows how to programmatically indicate a required rollback: diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-decl-explained.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-decl-explained.adoc index 87fa474557..fce9bb819d 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-decl-explained.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-decl-explained.adoc @@ -1,13 +1,13 @@ [[tx-decl-explained]] -= Understanding the Spring Framework's Declarative Transaction Implementation += Understanding the TODAY Framework's Declarative Transaction Implementation It is not sufficient merely to tell you to annotate your classes with the `@Transactional` annotation, add `@EnableTransactionManagement` to your configuration, and expect you to understand how it all works. To provide a deeper understanding, this -section explains the inner workings of the Spring Framework's declarative transaction +section explains the inner workings of the TODAY Framework's declarative transaction infrastructure in the context of transaction-related issues. -The most important concepts to grasp with regard to the Spring Framework's declarative +The most important concepts to grasp with regard to the TODAY Framework's declarative transaction support are that this support is enabled xref:core/aop/proxying.adoc#aop-understanding-aop-proxies[via AOP proxies] and that the transactional advice is driven by metadata (currently XML- or annotation-based). The combination of AOP @@ -17,7 +17,7 @@ around method invocations. NOTE: Infra AOP is covered in xref:core/aop.adoc[the AOP section]. -Spring Framework's `TransactionInterceptor` provides transaction management for +TODAY Framework's `TransactionInterceptor` provides transaction management for imperative and reactive programming models. The interceptor detects the desired flavor of transaction management by inspecting the method return type. Methods returning a reactive type such as `Publisher` or Kotlin `Flow` (or a subtype of those) qualify for reactive diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-propagation.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-propagation.adoc index 68da727e4f..e2b34eb204 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-propagation.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/declarative/tx-propagation.adoc @@ -75,6 +75,6 @@ that it can roll back to. Such partial rollbacks let an inner transaction scope trigger a rollback for its scope, with the outer transaction being able to continue the physical transaction despite some operations having been rolled back. This setting is typically mapped onto JDBC savepoints, so it works only with JDBC resource -transactions. See Spring's {today-framework-api}/jdbc/datasource/DataSourceTransactionManager.html[`DataSourceTransactionManager`]. +transactions. See Infra {today-framework-api}/jdbc/datasource/DataSourceTransactionManager.html[`DataSourceTransactionManager`]. diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/motivation.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/motivation.adoc index 60bf567d9c..5a92fe3052 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/motivation.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/motivation.adoc @@ -1,10 +1,10 @@ [[transaction-motivation]] -= Advantages of the Spring Framework's Transaction Support Model += Advantages of the TODAY Framework's Transaction Support Model Traditionally, EE application developers have had two choices for transaction management: global or local transactions, both of which have profound limitations. Global and local transaction management is reviewed in the next two sections, followed by a -discussion of how the Spring Framework's transaction management support addresses the +discussion of how the TODAY Framework's transaction management support addresses the limitations of the global and local transaction models. @@ -45,29 +45,29 @@ to the programming model. [[transaction-programming-model]] -== Spring Framework's Consistent Programming Model +== TODAY Framework's Consistent Programming Model Spring resolves the disadvantages of global and local transactions. It lets application developers use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction management -strategies in different environments. The Spring Framework provides both declarative and +strategies in different environments. The TODAY Framework provides both declarative and programmatic transaction management. Most users prefer declarative transaction management, which we recommend in most cases. -With programmatic transaction management, developers work with the Spring Framework +With programmatic transaction management, developers work with the TODAY Framework transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model, developers typically write little or no code -related to transaction management and, hence, do not depend on the Spring Framework +related to transaction management and, hence, do not depend on the TODAY Framework transaction API or any other transaction API. .Do you need an application server for transaction management? **** -The Spring Framework's transaction management support changes traditional rules as to +The TODAY Framework's transaction management support changes traditional rules as to when an enterprise Java application requires an application server. In particular, you do not need an application server purely for declarative transactions through EJBs. In fact, even if your application server has powerful JTA capabilities, -you may decide that the Spring Framework's declarative transactions offer more power and +you may decide that the TODAY Framework's declarative transactions offer more power and a more productive programming model than EJB CMT. Typically, you need an application server's JTA capability only if your application needs @@ -78,11 +78,11 @@ https://www.atomikos.com/[Atomikos Transactions]) are other options. Of course, you may need other application server capabilities, such as Java Message Service (JMS) and Jakarta EE Connector Architecture (JCA). -The Spring Framework gives you the choice of when to scale your application to a fully +The TODAY Framework gives you the choice of when to scale your application to a fully loaded application server. Gone are the days when the only alternative to using EJB CMT or JTA was to write code with local transactions (such as those on JDBC connections) and face a hefty rework if you need that code to run within global, container-managed -transactions. With the Spring Framework, only some of the bean definitions in your +transactions. With the TODAY Framework, only some of the bean definitions in your configuration file need to change (rather than your code). **** diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/programmatic.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/programmatic.adoc index b9d0dede4f..c7956c3856 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/programmatic.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/programmatic.adoc @@ -1,7 +1,7 @@ [[transaction-programmatic]] = Programmatic Transaction Management -The Spring Framework provides two means of programmatic transaction management, by using: +The TODAY Framework provides two means of programmatic transaction management, by using: * The `TransactionTemplate` or `TransactionalOperator`. * A `TransactionManager` implementation directly. @@ -22,7 +22,7 @@ code that is intention driven, in that your code focuses solely on what you want to do. NOTE: As the examples that follow show, using the `TransactionTemplate` absolutely -couples you to Spring's transaction infrastructure and APIs. Whether or not programmatic +couples you to Infra transaction infrastructure and APIs. Whether or not programmatic transaction management is suitable for your development needs is a decision that you have to make yourself. @@ -172,7 +172,7 @@ boilerplate acquisition and release transactional resources) and results in code intention driven, in that your code focuses solely on what you want to do. NOTE: As the examples that follow show, using the `TransactionalOperator` absolutely -couples you to Spring's transaction infrastructure and APIs. Whether or not programmatic +couples you to Infra transaction infrastructure and APIs. Whether or not programmatic transaction management is suitable for your development needs is a decision that you have to make yourself. diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/resources.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/resources.adoc index a8697e7709..b583b8fbab 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/resources.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/resources.adoc @@ -2,16 +2,16 @@ = Further Resources :page-section-summary-toc: 1 -For more information about the Spring Framework's transaction support, see: +For more information about the TODAY Framework's transaction support, see: * link:++https://www.infoworld.com/article/2077963/distributed-transactions-in-spring--with-and-without-xa.html++[ Distributed transactions in Spring, with and without XA] is a JavaWorld presentation in - which Spring's David Syer guides you through seven patterns for distributed transactions + which Infra David Syer guides you through seven patterns for distributed transactions in Spring applications, three of them with XA and four without. * https://www.infoq.com/minibooks/JTDS[_Java Transaction Design Strategies_] is a book available from https://www.infoq.com/[InfoQ] that provides a well-paced introduction to transactions in Java. It also includes side-by-side examples of how to configure - and use transactions with both the Spring Framework and EJB3. + and use transactions with both the TODAY Framework and EJB3. diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/solutions-to-common-problems.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/solutions-to-common-problems.adoc index 61789bbc0a..2c834390bc 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/solutions-to-common-problems.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/solutions-to-common-problems.adoc @@ -9,7 +9,7 @@ This section describes solutions to some common problems. == Using the Wrong Transaction Manager for a Specific `DataSource` Use the correct `PlatformTransactionManager` implementation based on your choice of -transactional technologies and requirements. Used properly, the Spring Framework merely +transactional technologies and requirements. Used properly, the TODAY Framework merely provides a straightforward and portable abstraction. If you use global transactions, you must use the `cn.taketoday.transaction.jta.JtaTransactionManager` class (or an diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc index 893454d6e1..d9333e5685 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/strategies.adoc @@ -1,5 +1,5 @@ [[transaction-strategies]] -= Understanding the Spring Framework Transaction Abstraction += Understanding the TODAY Framework Transaction Abstraction The key to the Spring transaction abstraction is the notion of a transaction strategy. A transaction strategy is defined by a `TransactionManager`, specifically the @@ -26,11 +26,11 @@ xref:data-access/transaction/programmatic.adoc#transaction-programmatic-ptm[prog `PlatformTransactionManager` is an interface, it can be easily mocked or stubbed as necessary. It is not tied to a lookup strategy, such as JNDI. `PlatformTransactionManager` implementations are defined like any other object (or bean) -in the Spring Framework IoC container. This benefit alone makes Spring Framework +in the TODAY Framework IoC container. This benefit alone makes TODAY Framework transactions a worthwhile abstraction, even when you work with JTA. You can test transactional code much more easily than if it used JTA directly. -Again, in keeping with Spring's philosophy, the `TransactionException` that can be thrown +Again, in keeping with Infra philosophy, the `TransactionException` that can be thrown by any of the `PlatformTransactionManager` interface's methods is unchecked (that is, it extends the `java.lang.RuntimeException` class). Transaction infrastructure failures are almost invariably fatal. In rare cases where application code can actually @@ -45,7 +45,7 @@ exists in the current call stack. The implication in this latter case is that, a Jakarta EE transaction contexts, a `TransactionStatus` is associated with a thread of execution. -As of Spring Framework 5.2, Spring also provides a transaction management abstraction for +As of TODAY Framework 5.2, Spring also provides a transaction management abstraction for reactive applications that make use of reactive types or Kotlin Coroutines. The following listing shows the transaction strategy defined by `cn.taketoday.transaction.ReactiveTransactionManager`: @@ -87,7 +87,7 @@ The `TransactionDefinition` interface specifies: These settings reflect standard transactional concepts. If necessary, refer to resources that discuss transaction isolation levels and other core transaction concepts. -Understanding these concepts is essential to using the Spring Framework or any +Understanding these concepts is essential to using the TODAY Framework or any transaction management solution. The `TransactionStatus` interface provides a simple way for transactional code to @@ -149,7 +149,7 @@ The related `PlatformTransactionManager` bean definition then has a reference to ---- If you use JTA in a Jakarta EE container, then you use a container `DataSource`, obtained -through JNDI, in conjunction with Spring's `JtaTransactionManager`. The following example +through JNDI, in conjunction with Infra `JtaTransactionManager`. The following example shows what the JTA and JNDI lookup version would look like: [source,xml,indent=0,subs="verbatim,quotes"] @@ -203,7 +203,7 @@ and, thus, is not shown in the following example. NOTE: If the `DataSource` (used by any non-JTA transaction manager) is looked up through JNDI and managed by a Jakarta EE container, it should be non-transactional, because the -Spring Framework (rather than the Jakarta EE container) manages the transactions. +TODAY Framework (rather than the Jakarta EE container) manages the transactions. The `txManager` bean in this case is of the `HibernateTransactionManager` type. In the same way as the `DataSourceTransactionManager` needs a reference to the `DataSource`, the diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/tx-decl-vs-prog.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/tx-decl-vs-prog.adoc index ece5dd419c..9d2795bf96 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/tx-decl-vs-prog.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/tx-decl-vs-prog.adoc @@ -13,7 +13,7 @@ to transaction management. On the other hand, if your application has numerous transactional operations, declarative transaction management is usually worthwhile. It keeps transaction management out of business logic and is not difficult to configure. When using the -Spring Framework, rather than EJB CMT, the configuration cost of declarative transaction +TODAY Framework, rather than EJB CMT, the configuration cost of declarative transaction management is greatly reduced. diff --git a/infra-docs/modules/ROOT/pages/data-access/transaction/tx-resource-synchronization.adoc b/infra-docs/modules/ROOT/pages/data-access/transaction/tx-resource-synchronization.adoc index 6fdaa3f02c..5c6942b458 100644 --- a/infra-docs/modules/ROOT/pages/data-access/transaction/tx-resource-synchronization.adoc +++ b/infra-docs/modules/ROOT/pages/data-access/transaction/tx-resource-synchronization.adoc @@ -14,7 +14,7 @@ relevant `TransactionManager`. [[tx-resource-synchronization-high]] == High-level Synchronization Approach -The preferred approach is to use Spring's highest-level template-based persistence +The preferred approach is to use Infra highest-level template-based persistence integration APIs or to use native ORM APIs with transaction-aware factory beans or proxies for managing the native resource factories. These transaction-aware solutions internally handle resource creation and reuse, cleanup, optional transaction @@ -31,12 +31,12 @@ sections of this reference documentation. Classes such as `DataSourceUtils` (for JDBC), `EntityManagerFactoryUtils` (for JPA), `SessionFactoryUtils` (for Hibernate), and so on exist at a lower level. When you want the application code to deal directly with the resource types of the native persistence APIs, -you use these classes to ensure that proper Spring Framework-managed instances are obtained, +you use these classes to ensure that proper TODAY Framework-managed instances are obtained, transactions are (optionally) synchronized, and exceptions that occur in the process are properly mapped to a consistent API. For example, in the case of JDBC, instead of the traditional JDBC approach of calling -the `getConnection()` method on the `DataSource`, you can instead use Spring's +the `getConnection()` method on the `DataSource`, you can instead use Infra `cn.taketoday.jdbc.datasource.DataSourceUtils` class, as follows: [source,java,indent=0,subs="verbatim,quotes"] @@ -48,8 +48,8 @@ If an existing transaction already has a connection synchronized (linked) to it, instance is returned. Otherwise, the method call triggers the creation of a new connection, which is (optionally) synchronized to any existing transaction and made available for subsequent reuse in that same transaction. As mentioned earlier, any -`SQLException` is wrapped in a Spring Framework `CannotGetJdbcConnectionException`, one -of the Spring Framework's hierarchy of unchecked `DataAccessException` types. This approach +`SQLException` is wrapped in a TODAY Framework `CannotGetJdbcConnectionException`, one +of the TODAY Framework's hierarchy of unchecked `DataAccessException` types. This approach gives you more information than can be obtained easily from the `SQLException` and ensures portability across databases and even across different persistence technologies. @@ -57,7 +57,7 @@ This approach also works without Spring transaction management (transaction synchronization is optional), so you can use it whether or not you use Spring for transaction management. -Of course, once you have used Spring's JDBC support, JPA support, or Hibernate support, +Of course, once you have used Infra JDBC support, JPA support, or Hibernate support, you generally prefer not to use `DataSourceUtils` or the other helper classes, because you are much happier working through the Spring abstraction than directly with the relevant APIs. For example, if you use the Spring `JdbcTemplate` or diff --git a/infra-docs/modules/ROOT/pages/integration.adoc b/infra-docs/modules/ROOT/pages/integration.adoc index aa24424d1b..af1b2b2f71 100644 --- a/infra-docs/modules/ROOT/pages/integration.adoc +++ b/infra-docs/modules/ROOT/pages/integration.adoc @@ -1,8 +1,8 @@ -[[spring-integration]] +[[today-integration]] = 集成 :page-section-summary-toc: 1 -This part of the reference documentation covers Spring Framework's integration with +This part of the reference documentation covers TODAY Framework's integration with a number of technologies. diff --git a/infra-docs/modules/ROOT/pages/integration/appendix.adoc b/infra-docs/modules/ROOT/pages/integration/appendix.adoc index d28d09bf44..2ac31a4666 100644 --- a/infra-docs/modules/ROOT/pages/integration/appendix.adoc +++ b/infra-docs/modules/ROOT/pages/integration/appendix.adoc @@ -280,7 +280,7 @@ xref:integration/jmx/naming.adoc#jmx-context-mbeanexport[Configuring Annotation- [[appendix.xsd-schemas-cache]] === The `cache` Schema -You can use the `cache` elements to enable support for Spring's `@CacheEvict`, `@CachePut`, +You can use the `cache` elements to enable support for Infra `@CacheEvict`, `@CachePut`, and `@Caching` annotations. It it also supports declarative XML-based caching. See xref:integration/cache/annotations.adoc#cache-annotation-enable[Enabling Caching Annotations] and xref:integration/cache/declarative-xml.adoc[Declarative XML-based Caching] for details. diff --git a/infra-docs/modules/ROOT/pages/integration/cache.adoc b/infra-docs/modules/ROOT/pages/integration/cache.adoc index 2f763a709d..153f6c73f0 100644 --- a/infra-docs/modules/ROOT/pages/integration/cache.adoc +++ b/infra-docs/modules/ROOT/pages/integration/cache.adoc @@ -2,12 +2,12 @@ = Cache Abstraction :page-section-summary-toc: 1 -Since version 3.1, the Spring Framework provides support for transparently adding caching to +Since version 3.1, the TODAY Framework provides support for transparently adding caching to an existing Spring application. Similar to the xref:data-access/transaction.adoc[transaction] support, the caching abstraction allows consistent use of various caching solutions with minimal impact on the code. -In Spring Framework 4.1, the cache abstraction was significantly extended with support +In TODAY Framework 4.1, the cache abstraction was significantly extended with support for xref:integration/cache/jsr-107.adoc[JSR-107 annotations] and more customization options. diff --git a/infra-docs/modules/ROOT/pages/integration/cache/annotations.adoc b/infra-docs/modules/ROOT/pages/integration/cache/annotations.adoc index 92e66f8fe6..c937c1a1ae 100644 --- a/infra-docs/modules/ROOT/pages/integration/cache/annotations.adoc +++ b/infra-docs/modules/ROOT/pages/integration/cache/annotations.adoc @@ -1,7 +1,7 @@ [[cache-annotations]] = Declarative Annotation-based Caching -For caching declaration, Spring's caching abstraction provides a set of Java annotations: +For caching declaration, Infra caching abstraction provides a set of Java annotations: * `@Cacheable`: Triggers cache population. * `@CacheEvict`: Triggers cache eviction. @@ -591,10 +591,10 @@ required to implement `CachingConfigurer`, see the | `mode` | `mode` | `proxy` -| The default mode (`proxy`) processes annotated beans to be proxied by using Spring's AOP +| The default mode (`proxy`) processes annotated beans to be proxied by using Infra AOP framework (following proxy semantics, as discussed earlier, applying to method calls coming in through the proxy only). The alternative mode (`aspectj`) instead weaves the - affected classes with Spring's AspectJ caching aspect, modifying the target class byte + affected classes with Infra AspectJ caching aspect, modifying the target class byte code to apply to any kind of method call. AspectJ weaving requires `spring-aspects.jar` in the classpath as well as load-time weaving (or compile-time weaving) enabled. (See xref:core/aop/using-aspectj.adoc#aop-aj-ltw-spring[Spring configuration] for details on how to set up diff --git a/infra-docs/modules/ROOT/pages/integration/cache/jsr-107.adoc b/infra-docs/modules/ROOT/pages/integration/cache/jsr-107.adoc index 08e3b5912c..d7713213ab 100644 --- a/infra-docs/modules/ROOT/pages/integration/cache/jsr-107.adoc +++ b/infra-docs/modules/ROOT/pages/integration/cache/jsr-107.adoc @@ -1,13 +1,13 @@ [[cache-jsr-107]] = JCache (JSR-107) Annotations -Since version 4.1, Spring's caching abstraction fully supports the JCache standard +Since version 4.1, Infra caching abstraction fully supports the JCache standard (JSR-107) annotations: `@CacheResult`, `@CachePut`, `@CacheRemove`, and `@CacheRemoveAll` as well as the `@CacheDefaults`, `@CacheKey`, and `@CacheValue` companions. You can use these annotations even without migrating your cache store to JSR-107. -The internal implementation uses Spring's caching abstraction and provides default +The internal implementation uses Infra caching abstraction and provides default `CacheResolver` and `KeyGenerator` implementations that are compliant with the -specification. In other words, if you are already using Spring's caching abstraction, +specification. In other words, if you are already using Infra caching abstraction, you can switch to these standard annotations without changing your cache storage (or configuration, for that matter). @@ -15,7 +15,7 @@ you can switch to these standard annotations without changing your cache storage [[cache-jsr-107-summary]] == Feature Summary -For those who are familiar with Spring's caching annotations, the following table +For those who are familiar with Infra caching annotations, the following table describes the main differences between the Spring annotations and their JSR-107 counterparts: @@ -51,7 +51,7 @@ counterparts: |=== JCache has the notion of `javax.cache.annotation.CacheResolver`, which is identical -to the Spring's `CacheResolver` interface, except that JCache supports only a single +to the Infra `CacheResolver` interface, except that JCache supports only a single cache. By default, a simple implementation retrieves the cache to use based on the name declared on the annotation. It should be noted that, if no cache name is specified on the annotation, a default is automatically generated. See the javadoc @@ -72,11 +72,11 @@ If more than one match exists, a new instance is created and can use the regular bean lifecycle callbacks, such as dependency injection. Keys are generated by a `javax.cache.annotation.CacheKeyGenerator` that serves the -same purpose as Spring's `KeyGenerator`. By default, all method arguments are taken +same purpose as Infra `KeyGenerator`. By default, all method arguments are taken into account, unless at least one parameter is annotated with `@CacheKey`. This is -similar to Spring's xref:integration/cache/annotations.adoc#cache-annotations-cacheable-key[custom key generation declaration] +similar to Infra xref:integration/cache/annotations.adoc#cache-annotations-cacheable-key[custom key generation declaration] . For instance, the following are identical operations, one using -Spring's abstraction and the other using JCache: +Infra abstraction and the other using JCache: [source,java,indent=0,subs="verbatim,quotes"] ---- @@ -109,13 +109,13 @@ public Book findBook(ISBN isbn) [[enabling-jsr-107-support]] == Enabling JSR-107 Support -You do not need to do anything specific to enable the JSR-107 support alongside Spring's +You do not need to do anything specific to enable the JSR-107 support alongside Infra declarative annotation support. Both `@EnableCaching` and the `cache:annotation-driven` XML element automatically enable the JCache support if both the JSR-107 API and the `spring-context-support` module are present in the classpath. NOTE: Depending on your use case, the choice is basically yours. You can even mix and -match services by using the JSR-107 API on some and using Spring's own annotations on +match services by using the JSR-107 API on some and using Infra own annotations on others. However, if these services impact the same caches, you should use a consistent and identical key generation implementation. diff --git a/infra-docs/modules/ROOT/pages/integration/cache/store-configuration.adoc b/infra-docs/modules/ROOT/pages/integration/cache/store-configuration.adoc index e06672ce44..b5c3d3be0a 100644 --- a/infra-docs/modules/ROOT/pages/integration/cache/store-configuration.adoc +++ b/infra-docs/modules/ROOT/pages/integration/cache/store-configuration.adoc @@ -90,7 +90,7 @@ use GemFire as a `CacheManager` (and more). [[cache-store-configuration-jsr107]] == JSR-107 Cache -Spring's caching abstraction can also use JSR-107-compliant caches. The JCache +Infra caching abstraction can also use JSR-107-compliant caches. The JCache implementation is located in the `cn.taketoday.cache.jcache` package. Again, to use it, you need to declare the appropriate `CacheManager`. diff --git a/infra-docs/modules/ROOT/pages/integration/cache/strategies.adoc b/infra-docs/modules/ROOT/pages/integration/cache/strategies.adoc index c7b9e75d17..0539196ab0 100644 --- a/infra-docs/modules/ROOT/pages/integration/cache/strategies.adoc +++ b/infra-docs/modules/ROOT/pages/integration/cache/strategies.adoc @@ -39,7 +39,7 @@ The caching abstraction provides other cache-related operations, such as the abi to update the content of the cache or to remove one or all entries. These are useful if the cache deals with data that can change during the course of the application. -As with other services in the Spring Framework, the caching service is an abstraction +As with other services in the TODAY Framework, the caching service is an abstraction (not a cache implementation) and requires the use of actual storage to store the cache data -- that is, the abstraction frees you from having to write the caching logic but does not provide the actual data store. This abstraction is materialized by the diff --git a/infra-docs/modules/ROOT/pages/integration/cds.adoc b/infra-docs/modules/ROOT/pages/integration/cds.adoc index ef1cc5c5d5..f9ca0354ba 100644 --- a/infra-docs/modules/ROOT/pages/integration/cds.adoc +++ b/infra-docs/modules/ROOT/pages/integration/cds.adoc @@ -6,7 +6,7 @@ Class Data Sharing (CDS) is a https://docs.oracle.com/en/java/javase/17/vm/class that can help reduce the startup time and memory footprint of Java applications. To use this feature, a CDS archive should be created for the particular classpath of the -application. The Spring Framework provides a hook-point to ease the creation of the +application. The TODAY Framework provides a hook-point to ease the creation of the archive. Once the archive is available, users should opt in to use it via a JVM flag. == Creating the CDS Archive diff --git a/infra-docs/modules/ROOT/pages/integration/checkpoint-restore.adoc b/infra-docs/modules/ROOT/pages/integration/checkpoint-restore.adoc index 137e79efeb..5a286a772b 100644 --- a/infra-docs/modules/ROOT/pages/integration/checkpoint-restore.adoc +++ b/infra-docs/modules/ROOT/pages/integration/checkpoint-restore.adoc @@ -1,7 +1,7 @@ [[checkpoint-restore]] = JVM Checkpoint Restore -The Spring Framework integrates with checkpoint/restore as implemented by https://github.com/CRaC/docs[Project CRaC] in order to allow implementing systems capable of reducing the startup and warmup times of Spring-based Java applications with the JVM. +The TODAY Framework integrates with checkpoint/restore as implemented by https://github.com/CRaC/docs[Project CRaC] in order to allow implementing systems capable of reducing the startup and warmup times of Spring-based Java applications with the JVM. Using this feature requires: diff --git a/infra-docs/modules/ROOT/pages/integration/email.adoc b/infra-docs/modules/ROOT/pages/integration/email.adoc index 2f85812e5c..9cce7673ee 100644 --- a/infra-docs/modules/ROOT/pages/integration/email.adoc +++ b/infra-docs/modules/ROOT/pages/integration/email.adoc @@ -1,12 +1,12 @@ [[mail]] = Email -This section describes how to send email with the Spring Framework. +This section describes how to send email with the TODAY Framework. .Library dependencies **** The following JAR needs to be on the classpath of your application in order to use the -Spring Framework's email support: +TODAY Framework's email support: * The https://jakartaee.github.io/mail-api/[Jakarta Mail] library @@ -16,7 +16,7 @@ the `jakarta.mail` package namespace) rather than Jakarta Mail 1.6.x (which uses `javax.mail` package namespace). **** -The Spring Framework provides a helpful utility library for sending email that shields +The TODAY Framework provides a helpful utility library for sending email that shields you from the specifics of the underlying mailing system and is responsible for low-level resource handling on behalf of the client. @@ -184,7 +184,7 @@ NOTE: The mail code is a crosscutting concern and could well be a candidate for refactoring into a xref:core/aop.adoc[custom Infra AOP aspect], which could then be run at appropriate joinpoints on the `OrderManager` target. -The Spring Framework's mail support ships with the standard JavaMail implementation. +The TODAY Framework's mail support ships with the standard JavaMail implementation. See the relevant javadoc for more information. @@ -298,6 +298,6 @@ Typically, the approach taken to address these issues is to use a template libra as FreeMarker) to define the display structure of email content. This leaves your code tasked only with creating the data that is to be rendered in the email template and sending the email. It is definitely a best practice when the content of your email messages -becomes even moderately complex, and, with the Spring Framework's support classes for +becomes even moderately complex, and, with the TODAY Framework's support classes for FreeMarker, it becomes quite easy to do. diff --git a/infra-docs/modules/ROOT/pages/integration/jmx.adoc b/infra-docs/modules/ROOT/pages/integration/jmx.adoc index 40e2bcd009..d65dd2022f 100644 --- a/infra-docs/modules/ROOT/pages/integration/jmx.adoc +++ b/infra-docs/modules/ROOT/pages/integration/jmx.adoc @@ -10,7 +10,7 @@ This chapter is not an introduction to JMX. It does not try to explain why you m to use JMX. If you are new to JMX, see xref:integration/jmx/resources.adoc[Further Resources] at the end of this chapter. **** -Specifically, Spring's JMX support provides four core features: +Specifically, Infra JMX support provides four core features: * The automatic registration of any Spring bean as a JMX MBean. * A flexible mechanism for controlling the management interface of your beans. diff --git a/infra-docs/modules/ROOT/pages/integration/jmx/exporting.adoc b/infra-docs/modules/ROOT/pages/integration/jmx/exporting.adoc index 7b5a448e18..fa3a6a3c39 100644 --- a/infra-docs/modules/ROOT/pages/integration/jmx/exporting.adoc +++ b/infra-docs/modules/ROOT/pages/integration/jmx/exporting.adoc @@ -1,7 +1,7 @@ [[jmx-exporting]] = Exporting Your Beans to JMX -The core class in Spring's JMX framework is the `MBeanExporter`. This class is +The core class in Infra JMX framework is the `MBeanExporter`. This class is responsible for taking your Spring beans and registering them with a JMX `MBeanServer`. For example, consider the following class: @@ -223,7 +223,7 @@ instance has already been registered under that same `ObjectName`, the default b is to fail (and throw an `InstanceAlreadyExistsException`). You can control exactly what happens when an `MBean` is -registered with an `MBeanServer`. Spring's JMX support allows for three different +registered with an `MBeanServer`. Infra JMX support allows for three different registration behaviors to control the registration behavior when the registration process finds that an `MBean` has already been registered under the same `ObjectName`. The following table summarizes these registration behaviors: diff --git a/infra-docs/modules/ROOT/pages/integration/jmx/notifications.adoc b/infra-docs/modules/ROOT/pages/integration/jmx/notifications.adoc index 73e2db2d6b..b280e47325 100644 --- a/infra-docs/modules/ROOT/pages/integration/jmx/notifications.adoc +++ b/infra-docs/modules/ROOT/pages/integration/jmx/notifications.adoc @@ -1,15 +1,15 @@ [[jmx-notifications]] = Notifications -Spring's JMX offering includes comprehensive support for JMX notifications. +Infra JMX offering includes comprehensive support for JMX notifications. [[jmx-notifications-listeners]] == Registering Listeners for Notifications -Spring's JMX support makes it easy to register any number of +Infra JMX support makes it easy to register any number of `NotificationListeners` with any number of MBeans (this includes MBeans exported by -Spring's `MBeanExporter` and MBeans registered through some other mechanism). For +Infra `MBeanExporter` and MBeans registered through some other mechanism). For example, consider the scenario where one would like to be informed (through a `Notification`) each and every time an attribute of a target MBean changes. The following example writes notifications to the console: @@ -236,7 +236,7 @@ NOTE: This section is really only relevant to Spring-managed beans that have been exposed as MBeans through an `MBeanExporter`. Any existing user-defined MBeans should use the standard JMX APIs for notification publication. -The key interface in Spring's JMX notification publication support is the +The key interface in Infra JMX notification publication support is the `NotificationPublisher` interface (defined in the `cn.taketoday.jmx.export.notification` package). Any bean that is going to be exported as an MBean through an `MBeanExporter` instance can implement the related @@ -249,7 +249,7 @@ As stated in the javadoc of the {today-framework-api}/jmx/export/notification/NotificationPublisher.html[`NotificationPublisher`] interface, managed beans that publish events through the `NotificationPublisher` mechanism are not responsible for the state management of notification listeners. -Spring's JMX support takes care of handling all the JMX infrastructure issues. +Infra JMX support takes care of handling all the JMX infrastructure issues. All you need to do, as an application developer, is implement the `NotificationPublisherAware` interface and start publishing events by using the supplied `NotificationPublisher` instance. Note that the `NotificationPublisher` @@ -299,7 +299,7 @@ public class JmxTestBean implements IJmxTestBean, NotificationPublisherAware { ---- The `NotificationPublisher` interface and the machinery to get it all working is one of -the nicer features of Spring's JMX support. It does, however, come with the price tag of +the nicer features of Infra JMX support. It does, however, come with the price tag of coupling your classes to both Spring and JMX. As always, the advice here is to be pragmatic. If you need the functionality offered by the `NotificationPublisher` and you can accept the coupling to both Spring and JMX, then do so. diff --git a/infra-docs/modules/ROOT/pages/integration/rest-clients.adoc b/infra-docs/modules/ROOT/pages/integration/rest-clients.adoc index 20c6e146ac..5732069459 100644 --- a/infra-docs/modules/ROOT/pages/integration/rest-clients.adoc +++ b/infra-docs/modules/ROOT/pages/integration/rest-clients.adoc @@ -1,7 +1,7 @@ [[rest-client-access]] = REST Clients -The Spring Framework provides the following choices for making calls to REST endpoints: +The TODAY Framework provides the following choices for making calls to REST endpoints: * xref:integration/rest-clients.adoc#rest-restclient[`RestClient`] - synchronous client with a fluent API. * xref:integration/rest-clients.adoc#rest-webclient[`WebClient`] - non-blocking, reactive client with fluent API. @@ -255,7 +255,7 @@ By default, this converter supports all media types (`{asterisk}/{asterisk}`) an You can override this by setting the `supportedMediaTypes` property and overriding `getContentType(byte[])`. | `MarshallingHttpMessageConverter` -| An `HttpMessageConverter` implementation that can read and write XML by using Spring's `Marshaller` and `Unmarshaller` abstractions from the `cn.taketoday.oxm` package. +| An `HttpMessageConverter` implementation that can read and write XML by using Infra `Marshaller` and `Unmarshaller` abstractions from the `cn.taketoday.oxm` package. This converter requires a `Marshaller` and `Unmarshaller` before it can be used. You can inject these through constructor or bean properties. By default, this converter supports `text/xml` and `application/xml`. @@ -743,7 +743,7 @@ It can be used to migrate from the latter to the former. [[rest-http-interface]] == HTTP Interface -The Spring Framework lets you define an HTTP service as a Java interface with +The TODAY Framework lets you define an HTTP service as a Java interface with `@HttpExchange` methods. You can pass such an interface to `HttpServiceProxyFactory` to create a proxy which performs requests through an HTTP client such as `RestClient` diff --git a/infra-docs/modules/ROOT/pages/integration/scheduling.adoc b/infra-docs/modules/ROOT/pages/integration/scheduling.adoc index 9d8e6abe03..5d664a9191 100644 --- a/infra-docs/modules/ROOT/pages/integration/scheduling.adoc +++ b/infra-docs/modules/ROOT/pages/integration/scheduling.adoc @@ -1,7 +1,7 @@ [[scheduling]] = Task Execution and Scheduling -The Spring Framework provides abstractions for the asynchronous execution and scheduling of +The TODAY Framework provides abstractions for the asynchronous execution and scheduling of tasks with the `TaskExecutor` and `TaskScheduler` interfaces, respectively. Spring also features implementations of those interfaces that support thread pools or delegation to CommonJ within an application server environment. Ultimately, the use of these @@ -18,10 +18,10 @@ https://www.quartz-scheduler.org/[Quartz Scheduler]. Executors are the JDK name for the concept of thread pools. The "`executor`" naming is due to the fact that there is no guarantee that the underlying implementation is -actually a pool. An executor may be single-threaded or even synchronous. Spring's +actually a pool. An executor may be single-threaded or even synchronous. Infra abstraction hides implementation details between the Java SE and Jakarta EE environments. -Spring's `TaskExecutor` interface is identical to the `java.util.concurrent.Executor` +Infra `TaskExecutor` interface is identical to the `java.util.concurrent.Executor` interface. In fact, originally, its primary reason for existence was to abstract away the need for Java 5 when using thread pools. The interface has a single method (`execute(Runnable task)`) that accepts a task for execution based on the semantics @@ -67,7 +67,7 @@ The variants that Spring provides are as follows: replacing a CommonJ WorkManager for that purpose. As of 6.1, `ThreadPoolTaskExecutor` provides a pause/resume capability and graceful -shutdown through Spring's lifecycle management. There is also a new "virtualThreads" +shutdown through Infra lifecycle management. There is also a new "virtualThreads" option on `SimpleAsyncTaskExecutor` which is aligned with JDK 21's Virtual Threads, as well as a graceful shutdown capability for `SimpleAsyncTaskExecutor` as well. @@ -75,7 +75,7 @@ as well as a graceful shutdown capability for `SimpleAsyncTaskExecutor` as well. [[scheduling-task-executor-usage]] === Using a `TaskExecutor` -Spring's `TaskExecutor` implementations are commonly used with dependency injection. +Infra `TaskExecutor` implementations are commonly used with dependency injection. In the following example, we define a bean that uses the `ThreadPoolTaskExecutor` to asynchronously print out a set of messages: @@ -235,7 +235,7 @@ such `Triggers` externally and, therefore, easily modify or extend them. [[scheduling-task-scheduler-implementations]] === `TaskScheduler` implementations -As with Spring's `TaskExecutor` abstraction, the primary benefit of the `TaskScheduler` +As with Infra `TaskExecutor` abstraction, the primary benefit of the `TaskScheduler` arrangement is that an application's scheduling needs are decoupled from the deployment environment. This abstraction level is particularly relevant when deploying to an application server environment where threads should not be created directly by the @@ -244,14 +244,14 @@ that delegates to a JSR-236 `ManagedScheduledExecutorService` in a Jakarta EE en Whenever external thread management is not a requirement, a simpler alternative is a local `ScheduledExecutorService` setup within the application, which can be adapted -through Spring's `ConcurrentTaskScheduler`. As a convenience, Spring also provides a +through Infra `ConcurrentTaskScheduler`. As a convenience, Spring also provides a `ThreadPoolTaskScheduler`, which internally delegates to a `ScheduledExecutorService` to provide common bean-style configuration along the lines of `ThreadPoolTaskExecutor`. These variants work perfectly fine for locally embedded thread pool setups in lenient application server environments, as well -- in particular on Tomcat and Jetty. As of 6.1, `ThreadPoolTaskScheduler` provides a pause/resume capability and graceful -shutdown through Spring's lifecycle management. There is also a new option called +shutdown through Infra lifecycle management. There is also a new option called `SimpleAsyncTaskScheduler` which is aligned with JDK 21's Virtual Threads, using a single scheduler thread but firing up a new thread for every scheduled task execution (except for fixed-delay tasks which all operate on a single scheduler thread, so for @@ -405,7 +405,7 @@ Please make sure that your specified cron expressions etc do not accidentally ov [NOTE] ==== -As of Spring Framework 4.3, `@Scheduled` methods are supported on beans of any scope. +As of TODAY Framework 4.3, `@Scheduled` methods are supported on beans of any scope. Make sure that you are not initializing multiple instances of the same `@Scheduled` annotation class at runtime, unless you do want to schedule callbacks to each such @@ -419,7 +419,7 @@ container and once through the `@Configurable` aspect), with the consequence of [[scheduling-annotation-support-scheduled-reactive]] === The `@Scheduled` annotation on Reactive methods or Kotlin suspending functions -As of Spring Framework 6.1, `@Scheduled` methods are also supported on several types +As of TODAY Framework 6.1, `@Scheduled` methods are also supported on several types of reactive methods: - methods with a `Publisher` return type (or any concrete implementation of `Publisher`) @@ -456,7 +456,7 @@ All these types of methods must be declared without any arguments. In the case o suspending functions, the `kotlinx.coroutines.reactor` bridge must also be present to allow the framework to invoke a suspending function as a `Publisher`. -The Spring Framework will obtain a `Publisher` for the annotated method once and will +The TODAY Framework will obtain a `Publisher` for the annotated method once and will schedule a `Runnable` in which it subscribes to said `Publisher`. These inner regular subscriptions occur according to the corresponding `cron`/`fixedDelay`/`fixedRate` configuration. @@ -502,7 +502,7 @@ public Mono reactiveSomething() { [NOTE] ==== -When destroying the annotated bean or closing the application context, Spring Framework cancels +When destroying the annotated bean or closing the application context, TODAY 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 or even infinite publishers). @@ -554,7 +554,7 @@ Future returnSomething(int i) { ---- TIP: `@Async` methods may not only declare a regular `java.util.concurrent.Future` return -type but also Spring's `cn.taketoday.util.concurrent.ListenableFuture` or, as of +type but also Infra `cn.taketoday.util.concurrent.ListenableFuture` or, as of Spring 4.2, JDK 8's `java.util.concurrent.CompletableFuture`, for richer interaction with the asynchronous task and for immediate composition with further processing steps. @@ -592,7 +592,7 @@ public class SampleBeanInitializer { NOTE: There is no direct XML equivalent for `@Async`, since such methods should be designed for asynchronous execution in the first place, not externally re-declared to be asynchronous. -However, you can manually set up Spring's `AsyncExecutionInterceptor` with Infra AOP, +However, you can manually set up Infra `AsyncExecutionInterceptor` with Infra AOP, in combination with a custom pointcut. @@ -616,7 +616,7 @@ void doSomething(String s) { In this case, `"otherExecutor"` can be the name of any `Executor` bean in the Spring container, or it may be the name of a qualifier associated with any `Executor` (for example, -as specified with the `` element or Spring's `@Qualifier` annotation). +as specified with the `` element or Infra `@Qualifier` annotation). [[scheduling-annotation-support-exception]] @@ -758,7 +758,7 @@ The following example sets the `keep-alive` value to two minutes: [[scheduling-task-namespace-scheduled-tasks]] === The 'scheduled-tasks' Element -The most powerful feature of Spring's task namespace is the support for configuring +The most powerful feature of Infra task namespace is the support for configuring tasks to be scheduled within a Spring Application Context. This follows an approach similar to other "`method-invokers`" in Spring, such as that provided by the JMS namespace for configuring message-driven POJOs. Basically, a `ref` attribute can point to any diff --git a/infra-docs/modules/ROOT/pages/languages/dynamic.adoc b/infra-docs/modules/ROOT/pages/languages/dynamic.adoc index fd81145a3e..6cbb574e9d 100644 --- a/infra-docs/modules/ROOT/pages/languages/dynamic.adoc +++ b/infra-docs/modules/ROOT/pages/languages/dynamic.adoc @@ -1,15 +1,15 @@ [[dynamic-language]] = Dynamic Language Support -Spring provides comprehensive support for using classes and objects that have been -defined by using a dynamic language (such as Groovy) with Spring. This support lets -you write any number of classes in a supported dynamic language and have the Spring +Infra provides comprehensive support for using classes and objects that have been +defined by using a dynamic language (such as Groovy) with Infra. This support lets +you write any number of classes in a supported dynamic language and have the Infra container transparently instantiate, configure, and dependency inject the resulting objects. -Spring's scripting support primarily targets Groovy and BeanShell. Beyond those +Infra 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), +for integration with any JSR-223 capable language provider (as of Infra 4.2), e.g. JRuby. You can find fully working examples of where this dynamic language support can be @@ -25,7 +25,7 @@ The bulk of this chapter is concerned with describing the dynamic language suppo detail. Before diving into all of the ins and outs of the dynamic language support, we look at a quick example of a bean defined in a dynamic language. The dynamic language for this first bean is Groovy. (The basis of this example was taken from the -Spring test suite. If you want to see equivalent examples in any of the other +Infra test suite. If you want to see equivalent examples in any of the other supported languages, take a look at the source code). The next example shows the `Messenger` interface, which the Groovy bean is going to @@ -82,10 +82,10 @@ class GroovyMessenger implements Messenger { [NOTE] ==== To use the custom dynamic language tags to define dynamic-language-backed beans, you -need to have the XML Schema preamble at the top of your Spring XML configuration file. -You also need to use a Spring `ApplicationContext` implementation as your IoC +need to have the XML Schema preamble at the top of your Infra XML configuration file. +You also need to use a Infra `ApplicationContext` implementation as your IoC container. Using the dynamic-language-backed beans with a plain `BeanFactory` -implementation is supported, but you have to manage the plumbing of the Spring internals +implementation is supported, but you have to manage the plumbing of the Infra internals to do so. For more information on schema-based configuration, see xref:languages/dynamic.adoc#xsd-schemas-lang[XML Schema-based Configuration] @@ -132,7 +132,7 @@ Keep reading for the in-depth detail on the whys and wherefores of the preceding [[dynamic-language-beans]] == Defining Beans that Are Backed by Dynamic Languages -This section describes exactly how you define Spring-managed beans in any of the +This section describes exactly how you define Infra-managed beans in any of the supported dynamic languages. Note that this chapter does not attempt to explain the syntax and idioms of the supported @@ -161,7 +161,7 @@ The first two steps (testing and writing your dynamic language source files) are the scope of this chapter. See the language specification and reference manual for your chosen dynamic language and crack on with developing your dynamic language source files. You first want to read the rest of this chapter, though, as -Spring's dynamic language support does make some (small) assumptions about the contents +Infra dynamic language support does make some (small) assumptions about the contents of your dynamic language source files. @@ -190,7 +190,7 @@ later in this chapter detail this). ==== Refreshable Beans One of the (and perhaps the single) most compelling value adds of the dynamic language -support in Spring is the "`refreshable bean`" feature. +support in Infra is the "`refreshable bean`" feature. A refreshable bean is a dynamic-language-backed bean. With a small amount of configuration, a dynamic-language-backed bean can monitor changes in its underlying @@ -198,7 +198,7 @@ source file resource and then reload itself when the dynamic language source fil changed (for example, when you edit and save changes to the file on the file system). This lets you deploy any number of dynamic language source files as part of an -application, configure the Spring container to create beans backed by dynamic +application, configure the Infra container to create beans backed by dynamic language source files (using the mechanisms described in this chapter), and (later, as requirements change or some other external factor comes into play) edit a dynamic language source file and have any change they make be reflected in the bean that is @@ -213,7 +213,7 @@ Now we can take a look at an example to see how easy it is to start using refres beans. To turn on the refreshable beans feature, you have to specify exactly one additional attribute on the `` element of your bean definition. So, if we stick with xref:languages/dynamic.adoc#dynamic-language-a-first-example[the example] from earlier in -this chapter, the following example shows what we would change in the Spring XML +this chapter, the following example shows what we would change in the Infra XML configuration to effect refreshable beans: [source,xml,indent=0,subs="verbatim,quotes"] @@ -320,9 +320,9 @@ file system). ==== Inline Dynamic Language Source Files The dynamic language support can also cater to dynamic language source files that are -embedded directly in Spring bean definitions. More specifically, the +embedded directly in Infra bean definitions. More specifically, the `` element lets you define dynamic language source immediately -inside a Spring configuration file. An example might clarify how the inline script +inside a Infra configuration file. An example might clarify how the inline script feature works: [source,xml,indent=0,subs="verbatim,quotes"] @@ -344,9 +344,9 @@ feature works: ---- If we put to one side the issues surrounding whether it is good practice to define -dynamic language source inside a Spring configuration file, the `` +dynamic language source inside a Infra configuration file, the `` element can be useful in some scenarios. For instance, we might want to quickly add a -Spring `Validator` implementation to a Web MVC `Controller`. This is but a moment's +Infra `Validator` implementation to a Web MVC `Controller`. This is but a moment's work using inline source. (See xref:languages/dynamic.adoc#dynamic-language-scenarios-validators[Scripted Validators] for such an example.) @@ -354,7 +354,7 @@ example.) [[dynamic-language-beans-ctor-injection]] ==== Understanding Constructor Injection in the Context of Dynamic-language-backed Beans -There is one very important thing to be aware of with regard to Spring's dynamic +There is one very important thing to be aware of with regard to Infra dynamic language support. Namely, you can not (currently) supply constructor arguments to dynamic-language-backed beans (and, hence, constructor-injection is not available for dynamic-language-backed beans). In the interests of making this special handling of @@ -407,7 +407,7 @@ injection is the injection style favored by the overwhelming majority of develop [[dynamic-language-beans-groovy]] === Groovy Beans -This section describes how to use beans defined in Groovy in Spring. +This section describes how to use beans defined in Groovy in Infra. The Groovy homepage includes the following description: @@ -417,7 +417,7 @@ them available to Java developers using a Java-like syntax.`" If you have read this chapter straight from the top, you have already xref:languages/dynamic.adoc#dynamic-language-a-first-example[seen an example] of a Groovy-dynamic-language-backed -bean. Now consider another example (again using an example from the Spring test suite): +bean. Now consider another example (again using an example from the Infra test suite): [source,java,indent=0,subs="verbatim,quotes",chomp="-packages"] ---- @@ -479,7 +479,7 @@ complex example or see the examples xref:languages/dynamic.adoc#dynamic-language You must not define more than one class per Groovy source file. While this is perfectly legal in Groovy, it is (arguably) a bad practice. In the interests of a consistent -approach, you should (in the opinion of the Spring team) respect the standard Java +approach, you should (in the opinion of the Infra team) respect the standard Java conventions of one (public) class per source file. @@ -500,7 +500,7 @@ public interface GroovyObjectCustomizer { } ---- -The Spring Framework instantiates an instance of your Groovy-backed bean and then +The Infra Framework instantiates an instance of your Groovy-backed bean and then passes the created `GroovyObject` to the specified `GroovyObjectCustomizer` (if one has been defined). You can do whatever you like with the supplied `GroovyObject` reference. We expect that most people want to set a custom `MetaClass` with this @@ -525,10 +525,10 @@ public final class SimpleMethodTracingCustomizer implements GroovyObjectCustomiz } ---- -A full discussion of meta-programming in Groovy is beyond the scope of the Spring +A full discussion of meta-programming in Groovy is beyond the scope of the Infra reference manual. See the relevant section of the Groovy reference manual or do a search online. Plenty of articles address this topic. Actually, making use of a -`GroovyObjectCustomizer` is easy if you use the Spring namespace support, as the +`GroovyObjectCustomizer` is easy if you use the Infra namespace support, as the following example shows: [source,xml,indent=0,subs="verbatim,quotes"] @@ -542,7 +542,7 @@ following example shows: customizer-ref="tracingCustomizer"/> ---- -If you do not use the Spring namespace support, you can still use the +If you do not use the Infra namespace support, you can still use the `GroovyObjectCustomizer` functionality, as the following example shows: [source,xml,indent=0,subs="verbatim,quotes"] @@ -559,7 +559,7 @@ If you do not use the Spring namespace support, you can still use the ---- NOTE: You may also specify a Groovy `CompilationCustomizer` (such as an `ImportCustomizer`) -or even a full Groovy `CompilerConfiguration` object in the same place as Spring's +or even a full Groovy `CompilerConfiguration` object in the same place as Infra `GroovyObjectCustomizer`. Furthermore, you may set a common `GroovyClassLoader` with custom configuration for your beans at the `ConfigurableApplicationContext.setClassLoader` level; this also leads to shared `GroovyClassLoader` usage and is therefore recommendable in case of @@ -570,7 +570,7 @@ a large number of scripted beans (avoiding an isolated `GroovyClassLoader` insta [[dynamic-language-beans-bsh]] === BeanShell Beans -This section describes how to use BeanShell beans in Spring. +This section describes how to use BeanShell beans in Infra. The https://beanshell.github.io/intro.html[BeanShell homepage] includes the following description: @@ -583,8 +583,8 @@ closures like those in Perl and JavaScript. ---- In contrast to Groovy, BeanShell-backed bean definitions require some (small) additional -configuration. The implementation of the BeanShell dynamic language support in Spring is -interesting, because Spring creates a JDK dynamic proxy that implements all of the +configuration. The implementation of the BeanShell dynamic language support in Infra is +interesting, because Infra creates a JDK dynamic proxy that implements all of the interfaces that are specified in the `script-interfaces` attribute value of the `` element (this is why you must supply at least one interface in the value of the attribute, and, consequently, program to interfaces when you use BeanShell-backed @@ -621,7 +621,7 @@ void setMessage(String aMessage) { } ---- -The following example shows the Spring XML that defines an "`instance`" of the above +The following example shows the Infra XML that defines an "`instance`" of the above "`class`" (again, we use these terms very loosely here): [source,xml,indent=0,subs="verbatim,quotes"] @@ -642,9 +642,9 @@ BeanShell-based beans. [[dynamic-language-scenarios]] == Scenarios -The possible scenarios where defining Spring managed beans in a scripting language would +The possible scenarios where defining Infra managed beans in a scripting language would be beneficial are many and varied. This section describes two possible use cases for the -dynamic language support in Spring. +dynamic language support in Infra. @@ -661,7 +661,7 @@ editing one or more dynamic language source files and seeing those changes being immediately reflected in the state of a running application. Remember that, in the lightweight architectural model espoused by projects such as -Spring, you typically aim to have a really thin presentation layer, with all +Infra, you typically aim to have a really thin presentation layer, with all the meaty business logic of an application being contained in the domain and service layer classes. Developing Web MVC controllers as dynamic-language-backed beans lets you change presentation layer logic by editing and saving text files. Any @@ -713,7 +713,7 @@ class FortuneController implements Controller { [[dynamic-language-scenarios-validators]] === Scripted Validators -Another area of application development with Spring that may benefit from the +Another area of application development with Infra that may benefit from the flexibility afforded by dynamic-language-backed beans is that of validation. It can be easier to express complex validation logic by using a loosely typed dynamic language (that may also have support for inline regular expressions) as opposed to regular Java. @@ -727,8 +727,8 @@ NOTE: To effect the automatic "`pickup`" of any changes to dynamic-language-back beans, you have to enable the 'refreshable beans' feature. See xref:languages/dynamic.adoc#dynamic-language-refreshable-beans[Refreshable Beans] for a full and detailed treatment of this feature. -The following example shows a Spring `cn.taketoday.validation.Validator` -implemented by using the Groovy dynamic language (see xref:core/validation/validator.adoc[Validation using Spring’s Validator interface] +The following example shows a Infra `cn.taketoday.validation.Validator` +implemented by using the Groovy dynamic language (see xref:core/validation/validator.adoc[Validation using Infra’s Validator interface] for a discussion of the `Validator` interface): @@ -811,7 +811,7 @@ a xref:core/beans/factory-scopes.adoc#beans-factory-scopes-prototype[prototype]: ---- See xref:core/beans/factory-scopes.adoc[Bean Scopes] in xref:web/webmvc-view/mvc-xslt.adoc#mvc-view-xslt-beandefs[The IoC Container] -for a full discussion of the scoping support in the Spring Framework. +for a full discussion of the scoping support in the TODAY Framework. diff --git a/infra-docs/modules/ROOT/pages/languages/groovy.adoc b/infra-docs/modules/ROOT/pages/languages/groovy.adoc index 745101a993..b52ed8355a 100644 --- a/infra-docs/modules/ROOT/pages/languages/groovy.adoc +++ b/infra-docs/modules/ROOT/pages/languages/groovy.adoc @@ -6,7 +6,7 @@ Groovy is a powerful, optionally typed, and dynamic language, with static-typing compilation capabilities. It offers a concise syntax and integrates smoothly with any existing Java application. -The Spring Framework provides a dedicated `ApplicationContext` that supports a Groovy-based +The Infra Framework provides a dedicated `ApplicationContext` that supports a Groovy-based Bean Definition DSL. For more details, see xref:core/beans/basics.adoc#groovy-bean-definition-dsl[The Groovy Bean Definition DSL]. diff --git a/infra-docs/modules/ROOT/pages/overview.adoc b/infra-docs/modules/ROOT/pages/overview.adoc index 20552032e0..0de481ab3f 100644 --- a/infra-docs/modules/ROOT/pages/overview.adoc +++ b/infra-docs/modules/ROOT/pages/overview.adoc @@ -55,8 +55,8 @@ https://github.com/TAKETODAY/today-blog[today-blog] 本项目的诞生离不开以下项目： -* https://github.com/spring-projects/spring-framework[Spring Framework] -* https://github.com/spring-projects/spring-boot[Spring Boot] +* https://github.com/spring-projects/spring-framework[TODAY Framework] +* https://github.com/spring-projects/spring-boot[Infra App] * 感谢 https://www.jetbrains.com/?from=https://github.com/TAKETODAY/today-infrastructure[Jetbrains] 提供免费 IDE 开源授权 == 📄 开源协议 diff --git a/infra-docs/modules/ROOT/pages/testing.adoc b/infra-docs/modules/ROOT/pages/testing.adoc index 2b7e81e545..290f4b1e51 100644 --- a/infra-docs/modules/ROOT/pages/testing.adoc +++ b/infra-docs/modules/ROOT/pages/testing.adoc @@ -2,8 +2,8 @@ = 测试 :page-section-summary-toc: 1 -This chapter covers Spring's support for integration testing and best practices for unit -testing. The Spring team advocates test-driven development (TDD). The Spring team has +This chapter covers Infra support for integration testing and best practices for unit +testing. The Infra team advocates test-driven development (TDD). The Infra team has found that the correct use of inversion of control (IoC) certainly does make both unit and integration testing easier (in that the presence of setter methods and appropriate constructors on classes makes them easier to wire together in a test without having to diff --git a/infra-docs/modules/ROOT/pages/testing/annotations.adoc b/infra-docs/modules/ROOT/pages/testing/annotations.adoc index 844885ee0d..062d46a160 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations.adoc @@ -2,5 +2,5 @@ = Annotations :page-section-summary-toc: 1 -This section covers annotations that you can use when you test Spring applications. +This section covers annotations that you can use when you test Infra applications. diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc index fbcc8d0a73..792e738e5f 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit-jupiter.adoc @@ -1,29 +1,29 @@ [[integration-testing-annotations-junit-jupiter]] -= Spring JUnit Jupiter Testing Annotations += Infra JUnit Jupiter Testing Annotations The following annotations are supported when used in conjunction with the -xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-extension[`SpringExtension`] and JUnit Jupiter +xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-extension[`InfraExtension`] and JUnit Jupiter (that is, the programming model in JUnit 5): -* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-springjunitconfig[`@SpringJUnitConfig`] -* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-springjunitwebconfig[`@SpringJUnitWebConfig`] +* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-junitconfig[`@JUnitConfig`] +* xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-junitwebconfig[`@JUnitWebConfig`] * xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[`@TestConstructor`] * xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-nestedtestconfiguration[`@NestedTestConfiguration`] * xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-enabledif[`@EnabledIf`] * xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-junit-jupiter-disabledif[`@DisabledIf`] * xref:testing/annotations/integration-spring/annotation-disabledinaotmode.adoc[`@DisabledInAotMode`] -[[integration-testing-annotations-junit-jupiter-springjunitconfig]] -== `@SpringJUnitConfig` +[[integration-testing-annotations-junit-jupiter-junitconfig]] +== `@JUnitConfig` -`@SpringJUnitConfig` is a composed annotation that combines -`@ExtendWith(SpringExtension.class)` from JUnit Jupiter with `@ContextConfiguration` from -the Spring TestContext Framework. It can be used at the class level as a drop-in +`@JUnitConfig` is a composed annotation that combines +`@ExtendWith(InfraExtension.class)` from JUnit Jupiter with `@ContextConfiguration` from +the Infra TestContext Framework. It can be used at the class level as a drop-in replacement for `@ContextConfiguration`. With regard to configuration options, the only -difference between `@ContextConfiguration` and `@SpringJUnitConfig` is that component -classes may be declared with the `value` attribute in `@SpringJUnitConfig`. +difference between `@ContextConfiguration` and `@JUnitConfig` is that component +classes may be declared with the `value` attribute in `@JUnitConfig`. -The following example shows how to use the `@SpringJUnitConfig` annotation to specify a +The following example shows how to use the `@JUnitConfig` annotation to specify a configuration class: [tabs] @@ -32,8 +32,8 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) // <1> -class ConfigurationClassJUnitJupiterSpringTests { +@JUnitConfig(TestConfig.class) // <1> +class ConfigurationClassJUnitJupiterInfraTests { // class body... } ---- @@ -41,7 +41,7 @@ class ConfigurationClassJUnitJupiterSpringTests { ====== -The following example shows how to use the `@SpringJUnitConfig` annotation to specify the +The following example shows how to use the `@JUnitConfig` annotation to specify the location of a configuration file: [tabs] @@ -50,8 +50,8 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(locations = "/test-config.xml") // <1> -class XmlJUnitJupiterSpringTests { +@JUnitConfig(locations = "/test-config.xml") // <1> +class XmlJUnitJupiterInfraTests { // class body... } ---- @@ -61,23 +61,23 @@ class XmlJUnitJupiterSpringTests { See xref:testing/testcontext-framework/ctx-management.adoc[Context Management] as well as the javadoc for -{today-framework-api}/test/context/junit/jupiter/SpringJUnitConfig.html[`@SpringJUnitConfig`] +{today-framework-api}/test/context/junit/jupiter/JUnitConfig.html[`@JUnitConfig`] and `@ContextConfiguration` for further details. -[[integration-testing-annotations-junit-jupiter-springjunitwebconfig]] -== `@SpringJUnitWebConfig` +[[integration-testing-annotations-junit-jupiter-junitwebconfig]] +== `@JUnitWebConfig` -`@SpringJUnitWebConfig` is a composed annotation that combines -`@ExtendWith(SpringExtension.class)` from JUnit Jupiter with `@ContextConfiguration` and -`@WebAppConfiguration` from the Spring TestContext Framework. You can use it at the class +`@JUnitWebConfig` is a composed annotation that combines +`@ExtendWith(InfraExtension.class)` from JUnit Jupiter with `@ContextConfiguration` and +`@WebAppConfiguration` from the Infra TestContext Framework. You can use it at the class level as a drop-in replacement for `@ContextConfiguration` and `@WebAppConfiguration`. With regard to configuration options, the only difference between `@ContextConfiguration` -and `@SpringJUnitWebConfig` is that you can declare component classes by using the -`value` attribute in `@SpringJUnitWebConfig`. In addition, you can override the `value` +and `@JUnitWebConfig` is that you can declare component classes by using the +`value` attribute in `@JUnitWebConfig`. In addition, you can override the `value` attribute from `@WebAppConfiguration` only by using the `resourcePath` attribute in -`@SpringJUnitWebConfig`. +`@JUnitWebConfig`. -The following example shows how to use the `@SpringJUnitWebConfig` annotation to specify +The following example shows how to use the `@JUnitWebConfig` annotation to specify a configuration class: [tabs] @@ -86,8 +86,8 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig(TestConfig.class) // <1> -class ConfigurationClassJUnitJupiterSpringWebTests { +@JUnitWebConfig(TestConfig.class) // <1> +class ConfigurationClassJUnitJupiterInfraWebTests { // class body... } ---- @@ -96,7 +96,7 @@ class ConfigurationClassJUnitJupiterSpringWebTests { ====== -The following example shows how to use the `@SpringJUnitWebConfig` annotation to specify the +The following example shows how to use the `@JUnitWebConfig` annotation to specify the location of a configuration file: [tabs] @@ -105,8 +105,8 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig(locations = "/test-config.xml") // <1> -class XmlJUnitJupiterSpringWebTests { +@JUnitWebConfig(locations = "/test-config.xml") // <1> +class XmlJUnitJupiterInfraWebTests { // class body... } ---- @@ -116,7 +116,7 @@ class XmlJUnitJupiterSpringWebTests { See xref:testing/testcontext-framework/ctx-management.adoc[Context Management] as well as the javadoc for -{today-framework-api}/test/context/junit/jupiter/web/SpringJUnitWebConfig.html[`@SpringJUnitWebConfig`], +{today-framework-api}/test/context/junit/jupiter/web/JUnitWebConfig.html[`@JUnitWebConfig`], {today-framework-api}/test/context/ContextConfiguration.html[`@ContextConfiguration`], and {today-framework-api}/test/context/web/WebAppConfiguration.html[`@WebAppConfiguration`] for further details. @@ -140,7 +140,7 @@ over both `@TestConstructor` and the default mode. The default _test constructor autowire mode_ can be changed by setting the `spring.test.constructor.autowire.mode` JVM system property to `all`. Alternatively, the default mode may be set via the -xref:appendix.adoc#appendix-infra-properties[`SpringProperties`] mechanism. +xref:appendix.adoc#appendix-infra-properties[`InfraProperties`] mechanism. As of TODAY Framework 5.3, the default mode may also be configured as a https://junit.org/junit5/docs/current/user-guide/#running-tests-config-params[JUnit Platform configuration parameter]. @@ -150,16 +150,16 @@ constructors will not be automatically autowired. ===== NOTE: As of TODAY Framework 5.2, `@TestConstructor` is only supported in conjunction -with the `SpringExtension` for use with JUnit Jupiter. Note that the `SpringExtension` is +with the `InfraExtension` for use with JUnit Jupiter. Note that the `InfraExtension` is often automatically registered for you – for example, when using annotations such as -`@SpringJUnitConfig` and `@SpringJUnitWebConfig` or various test-related annotations from -Spring Boot Test. +`@JUnitConfig` and `@JUnitWebConfig` or various test-related annotations from +Infra App Test. [[integration-testing-annotations-nestedtestconfiguration]] == `@NestedTestConfiguration` `@NestedTestConfiguration` is a type-level annotation that is used to configure how -Spring test configuration annotations are processed within enclosing class hierarchies +Infra test configuration annotations are processed within enclosing class hierarchies for inner test classes. If `@NestedTestConfiguration` is not present or meta-present on a test class, in its @@ -173,10 +173,10 @@ change the default mode. The default _enclosing configuration inheritance mode_ is `INHERIT`, but it can be changed by setting the `spring.test.enclosing.configuration` JVM system property to `OVERRIDE`. Alternatively, the default mode may be set via the -xref:appendix.adoc#appendix-infra-properties[`SpringProperties`] mechanism. +xref:appendix.adoc#appendix-infra-properties[`InfraProperties`] mechanism. ===== -The xref:testing/testcontext-framework.adoc[Spring TestContext Framework] honors `@NestedTestConfiguration` semantics for the +The xref:testing/testcontext-framework.adoc[Infra TestContext Framework] honors `@NestedTestConfiguration` semantics for the following annotations. * xref:testing/annotations/integration-spring/annotation-bootstrapwith.adoc[`@BootstrapWith`] @@ -200,7 +200,7 @@ following annotations. NOTE: The use of `@NestedTestConfiguration` typically only makes sense in conjunction with `@Nested` test classes in JUnit Jupiter; however, there may be other testing -frameworks with support for Spring and nested test classes that make use of this +frameworks with support for Infra and nested test classes that make use of this annotation. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for an example and further @@ -219,7 +219,7 @@ Expressions can be any of the following: * xref:core/expressions.adoc[Spring Expression Language] (SpEL) expression. For example: `@EnabledIf("#{systemProperties['os.name'].toLowerCase().contains('mac')}")` -* Placeholder for a property available in the Spring xref:core/beans/environment.adoc[`Environment`]. +* Placeholder for a property available in the Infra xref:core/beans/environment.adoc[`Environment`]. For example: `@EnabledIf("${smoke.tests.enabled}")` * Text literal. For example: `@EnabledIf("true")` @@ -256,7 +256,7 @@ use case, please use the built-in `@EnabledOnOs(MAC)` support in JUnit Jupiter. [WARNING] ==== Since JUnit 5.7, JUnit Jupiter also has a condition annotation named `@EnabledIf`. Thus, -if you wish to use Spring's `@EnabledIf` support make sure you import the annotation type +if you wish to use Infra `@EnabledIf` support make sure you import the annotation type from the correct package. ==== @@ -273,7 +273,7 @@ Expressions can be any of the following: * xref:core/expressions.adoc[Spring Expression Language] (SpEL) expression. For example: `@DisabledIf("#{systemProperties['os.name'].toLowerCase().contains('mac')}")` -* Placeholder for a property available in the Spring xref:core/beans/environment.adoc[`Environment`]. +* Placeholder for a property available in the Infra xref:core/beans/environment.adoc[`Environment`]. For example: `@DisabledIf("${smoke.tests.disabled}")` * Text literal. For example: `@DisabledIf("true")` @@ -310,7 +310,7 @@ use case, please use the built-in `@DisabledOnOs(MAC)` support in JUnit Jupiter. [WARNING] ==== Since JUnit 5.7, JUnit Jupiter also has a condition annotation named `@DisabledIf`. Thus, -if you wish to use Spring's `@DisabledIf` support make sure you import the annotation type +if you wish to use Infra `@DisabledIf` support make sure you import the annotation type from the correct package. ==== diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit4.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit4.adoc index 7f0fabd72a..33a7417242 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit4.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-junit4.adoc @@ -1,9 +1,9 @@ [[integration-testing-annotations-junit4]] -= Spring JUnit 4 Testing Annotations += Infra JUnit 4 Testing Annotations The following annotations are supported only when used in conjunction with the -xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-runner[SpringRunner], xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Spring's JUnit 4 rules] -, or xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[Spring's JUnit 4 support classes]: +xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-runner[InfraRunner], xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Infra JUnit 4 rules] +, or xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[Infra JUnit 4 support classes]: * xref:testing/annotations/integration-junit4.adoc#integration-testing-annotations-junit4-ifprofilevalue[`@IfProfileValue`] * xref:testing/annotations/integration-junit4.adoc#integration-testing-annotations-junit4-profilevaluesourceconfiguration[`@ProfileValueSourceConfiguration`] @@ -116,10 +116,10 @@ public void testProcessWithOneSecondTimeout() { ====== -Spring's `@Timed` annotation has different semantics than JUnit 4's `@Test(timeout=...)` +Infra `@Timed` annotation has different semantics than JUnit 4's `@Test(timeout=...)` support. Specifically, due to the manner in which JUnit 4 handles test execution timeouts (that is, by executing the test method in a separate `Thread`), `@Test(timeout=...)` -preemptively fails the test if the test takes too long. Spring's `@Timed`, on the other +preemptively fails the test if the test takes too long. Infra `@Timed`, on the other hand, does not preemptively fail the test but rather waits for the test to complete before failing. @@ -131,7 +131,7 @@ times that the test method is to be run is specified in the annotation. The scope of execution to be repeated includes execution of the test method itself as well as any setting up or tearing down of the test fixture. When used with the -xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[`SpringMethodRule`], the scope additionally includes +xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[`InfraMethodRule`], the scope additionally includes preparation of the test instance by `TestExecutionListener` implementations. The following example shows how to use the `@Repeat` annotation: diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-meta.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-meta.adoc index 0d41e4f162..ba5d0c84ef 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-meta.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-meta.adoc @@ -30,8 +30,8 @@ xref:testing/testcontext-framework.adoc[TestContext framework]. * `@Timed` _(only supported on JUnit 4)_ * `@IfProfileValue` _(only supported on JUnit 4)_ * `@ProfileValueSourceConfiguration` _(only supported on JUnit 4)_ -* `@SpringJUnitConfig` _(only supported on JUnit Jupiter)_ -* `@SpringJUnitWebConfig` _(only supported on JUnit Jupiter)_ +* `@JUnitConfig` _(only supported on JUnit Jupiter)_ +* `@JUnitWebConfig` _(only supported on JUnit Jupiter)_ * `@TestConstructor` _(only supported on JUnit Jupiter)_ * `@NestedTestConfiguration` _(only supported on JUnit Jupiter)_ * `@EnabledIf` _(only supported on JUnit Jupiter)_ @@ -45,13 +45,13 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- - @RunWith(SpringRunner.class) + @RunWith(InfraRunner.class) @ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"}) @ActiveProfiles("dev") @Transactional public class OrderRepositoryTests { } - @RunWith(SpringRunner.class) + @RunWith(InfraRunner.class) @ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"}) @ActiveProfiles("dev") @Transactional @@ -62,7 +62,7 @@ Java:: If we discover that we are repeating the preceding configuration across our JUnit 4-based test suite, we can reduce the duplication by introducing a custom composed annotation -that centralizes the common test configuration for Spring, as follows: +that centralizes the common test configuration for Infra, as follows: [tabs] ====== @@ -89,11 +89,11 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- - @RunWith(SpringRunner.class) + @RunWith(InfraRunner.class) @TransactionalDevTestConfig public class OrderRepositoryTests { } - @RunWith(SpringRunner.class) + @RunWith(InfraRunner.class) @TransactionalDevTestConfig public class UserRepositoryTests { } ---- @@ -109,13 +109,13 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- - @ExtendWith(SpringExtension.class) + @ExtendWith(InfraExtension.class) @ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"}) @ActiveProfiles("dev") @Transactional class OrderRepositoryTests { } - @ExtendWith(SpringExtension.class) + @ExtendWith(InfraExtension.class) @ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"}) @ActiveProfiles("dev") @Transactional @@ -126,7 +126,7 @@ Java:: If we discover that we are repeating the preceding configuration across our JUnit Jupiter-based test suite, we can reduce the duplication by introducing a custom composed -annotation that centralizes the common test configuration for Spring and JUnit Jupiter, +annotation that centralizes the common test configuration for Infra and JUnit Jupiter, as follows: [tabs] @@ -137,7 +137,7 @@ Java:: ---- @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) - @ExtendWith(SpringExtension.class) + @ExtendWith(InfraExtension.class) @ContextConfiguration({"/app-config.xml", "/test-data-access-config.xml"}) @ActiveProfiles("dev") @Transactional @@ -168,7 +168,7 @@ Since JUnit Jupiter supports the use of `@Test`, `@RepeatedTest`, `Parameterized and others as meta-annotations, you can also create custom composed annotations at the test method level. For example, if we wish to create a composed annotation that combines the `@Test` and `@Tag` annotations from JUnit Jupiter with the `@Transactional` -annotation from Spring, we could create an `@TransactionalIntegrationTest` annotation, as +annotation from Infra, we could create an `@TransactionalIntegrationTest` annotation, as follows: [tabs] diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring.adoc index 3a7e07a673..f26ad277f2 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring.adoc @@ -1,12 +1,12 @@ [[integration-testing-annotations-spring]] -= Spring Testing Annotations += Infra Testing Annotations -The TODAY Framework provides the following set of Spring-specific annotations that you +The TODAY Framework provides the following set of Infra-specific annotations that you can use in your unit and integration tests in conjunction with the TestContext framework. See the corresponding javadoc for further information, including default attribute values, attribute aliases, and other details. -Spring's testing annotations include the following: +Infra testing annotations include the following: * xref:testing/annotations/integration-spring/annotation-bootstrapwith.adoc[`@BootstrapWith`] * xref:testing/annotations/integration-spring/annotation-contextconfiguration.adoc[`@ContextConfiguration`] diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-aftertransaction.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-aftertransaction.adoc index 9f38804605..fb4b60fccb 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-aftertransaction.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-aftertransaction.adoc @@ -3,7 +3,7 @@ `@AfterTransaction` indicates that the annotated `void` method should be run after a transaction is ended, for test methods that have been configured to run within a -transaction by using Spring's `@Transactional` annotation. `@AfterTransaction` methods +transaction by using Infra `@Transactional` annotation. `@AfterTransaction` methods are not required to be `public` and may be declared on Java 8-based interface default methods. diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beanoverriding.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beanoverriding.adoc index 6b9ced9adb..41d0222ff1 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beanoverriding.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beanoverriding.adoc @@ -8,8 +8,8 @@ NOTE: This is intended as a less risky alternative to the practice of registerin `@Bean` with the `DefaultListableBeanFactory` `setAllowBeanDefinitionOverriding` set to `true`. -The Spring Testing Framework provides two sets of annotations presented below. One relies -purely on Spring, while the second set relies on the Mockito third party library. +The Infra Testing Framework provides two sets of annotations presented below. One relies +purely on Infra, while the second set relies on the Mockito third party library. [[spring-testing-annotation-beanoverriding-testbean]] == `@TestBean` @@ -108,10 +108,10 @@ To create an extension, the following is needed: - The `BeanOverrideProcessor` implementation itself. - One or more concrete `OverrideMetadata` implementations provided by the processor. -The Spring TestContext Framework includes infrastructure classes that support bean +The Infra TestContext Framework includes infrastructure classes that support bean overriding: a `BeanFactoryPostProcessor`, a `TestExecutionListener` and a `ContextCustomizerFactory`. -The later two are automatically registered via the Spring TestContext Framework +The later two are automatically registered via the Infra TestContext Framework `spring.factories` file, and are responsible for setting up the rest of the infrastructure. The test classes are parsed looking for any field meta-annotated with `@BeanOverride`, diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beforetransaction.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beforetransaction.adoc index cb702a537c..b17a94e8d0 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beforetransaction.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-beforetransaction.adoc @@ -3,7 +3,7 @@ `@BeforeTransaction` indicates that the annotated `void` method should be run before a transaction is started, for test methods that have been configured to run within a -transaction by using Spring's `@Transactional` annotation. `@BeforeTransaction` methods +transaction by using Infra `@Transactional` annotation. `@BeforeTransaction` methods are not required to be `public` and may be declared on Java 8-based interface default methods. diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-bootstrapwith.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-bootstrapwith.adoc index 5769b3d3d3..191451b190 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-bootstrapwith.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-bootstrapwith.adoc @@ -2,7 +2,7 @@ = `@BootstrapWith` :page-section-summary-toc: 1 -`@BootstrapWith` is a class-level annotation that you can use to configure how the Spring +`@BootstrapWith` is a class-level annotation that you can use to configure how the Infra TestContext Framework is bootstrapped. Specifically, you can use `@BootstrapWith` to specify a custom `TestContextBootstrapper`. See the section on xref:testing/testcontext-framework/bootstrapping.adoc[bootstrapping the TestContext framework] for further details. diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-dirtiescontext.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-dirtiescontext.adoc index 5d08bb67fd..ae296d3f0a 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-dirtiescontext.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-dirtiescontext.adoc @@ -1,11 +1,11 @@ [[spring-testing-annotation-dirtiescontext]] = `@DirtiesContext` -`@DirtiesContext` indicates that the underlying Spring `ApplicationContext` has been +`@DirtiesContext` indicates that the underlying Infra `ApplicationContext` has been dirtied during the execution of a test (that is, the test modified or corrupted it in some manner -- for example, by changing the state of a singleton bean) and should be closed. When an application context is marked as dirty, it is removed from the testing -framework's cache and closed. As a consequence, the underlying Spring container is +framework's cache and closed. As a consequence, the underlying Infra container is rebuilt for any subsequent test that requires a context with the same configuration metadata. @@ -32,7 +32,7 @@ Java:: ---- @DirtiesContext(classMode = BEFORE_CLASS) // <1> class FreshContextTests { - // some tests that require a new Spring container + // some tests that require a new Infra container } ---- <1> Dirty the context before the current test class. @@ -49,7 +49,7 @@ Java:: ---- @DirtiesContext // <1> class ContextDirtyingTests { - // some tests that result in the Spring container being dirtied + // some tests that result in the Infra container being dirtied } ---- <1> Dirty the context after the current test class. @@ -67,7 +67,7 @@ Java:: ---- @DirtiesContext(classMode = BEFORE_EACH_TEST_METHOD) // <1> class FreshContextTests { - // some tests that require a new Spring container + // some tests that require a new Infra container } ---- <1> Dirty the context before each test method. @@ -85,7 +85,7 @@ Java:: ---- @DirtiesContext(classMode = AFTER_EACH_TEST_METHOD) // <1> class ContextDirtyingTests { - // some tests that result in the Spring container being dirtied + // some tests that result in the Infra container being dirtied } ---- <1> Dirty the context after each test method. @@ -104,7 +104,7 @@ Java:: @DirtiesContext(methodMode = BEFORE_METHOD) // <1> @Test void testProcessWhichRequiresFreshAppCtx() { - // some logic that requires a new Spring container + // some logic that requires a new Infra container } ---- <1> Dirty the context before the current test method. @@ -122,7 +122,7 @@ Java:: @DirtiesContext // <1> @Test void testProcessWhichDirtiesAppCtx() { - // some logic that results in the Spring container being dirtied + // some logic that results in the Infra container being dirtied } ---- <1> Dirty the context after the current test method. diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-disabledinaotmode.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-disabledinaotmode.adoc index 2fbfc6a19b..9895481ce1 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-disabledinaotmode.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-disabledinaotmode.adoc @@ -1,7 +1,7 @@ [[spring-testing-annotation-disabledinaotmode]] = `@DisabledInAotMode` -`@DisabledInAotMode` signals that an annotated test class is disabled in Spring AOT +`@DisabledInAotMode` signals that an annotated test class is disabled in Infra AOT (ahead-of-time) mode, which means that the `ApplicationContext` for the test class will not be processed for AOT optimizations at build time. @@ -11,7 +11,7 @@ specify configuration to load the same `ApplicationContext` must also be annotat exception, either at build time or run time. When used with JUnit Jupiter based tests, `@DisabledInAotMode` also signals that the -annotated test class or test method is disabled when running the test suite in Spring AOT +annotated test class or test method is disabled when running the test suite in Infra AOT mode. When applied at the class level, all test methods within that class will be disabled. In this sense, `@DisabledInAotMode` has semantics similar to those of JUnit Jupiter's `@DisabledInNativeImage` annotation. diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-recordapplicationevents.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-recordapplicationevents.adoc index f72fd70347..17740f8987 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-recordapplicationevents.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-recordapplicationevents.adoc @@ -3,7 +3,7 @@ :page-section-summary-toc: 1 `@RecordApplicationEvents` is a class-level annotation that is used to instruct the -_Spring TestContext Framework_ to record all application events that are published in the +_Infra TestContext Framework_ to record all application events that are published in the `ApplicationContext` during the execution of a single test. The recorded events can be accessed via the `ApplicationEvents` API within tests. diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-rollback.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-rollback.adoc index 54d9ac13fb..13f7c14a17 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-rollback.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-rollback.adoc @@ -4,7 +4,7 @@ `@Rollback` indicates whether the transaction for a transactional test method should be rolled back after the test method has completed. If `true`, the transaction is rolled back. Otherwise, the transaction is committed (see also -xref:testing/annotations/integration-spring/annotation-commit.adoc[`@Commit`]). Rollback for integration tests in the Spring +xref:testing/annotations/integration-spring/annotation-commit.adoc[`@Commit`]). Rollback for integration tests in the Infra TestContext Framework defaults to `true` even if `@Rollback` is not explicitly declared. When declared as a class-level annotation, `@Rollback` defines the default rollback diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-sqlmergemode.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-sqlmergemode.adoc index 3bb45fc42d..f8c3ba3ff8 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-sqlmergemode.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-spring/annotation-sqlmergemode.adoc @@ -17,7 +17,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) @Sql("/test-schema.sql") @SqlMergeMode(MERGE) // <1> class UserTests { @@ -40,7 +40,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) @Sql("/test-schema.sql") class UserTests { diff --git a/infra-docs/modules/ROOT/pages/testing/annotations/integration-standard.adoc b/infra-docs/modules/ROOT/pages/testing/annotations/integration-standard.adoc index 1afe3363a2..b23b68062d 100644 --- a/infra-docs/modules/ROOT/pages/testing/annotations/integration-standard.adoc +++ b/infra-docs/modules/ROOT/pages/testing/annotations/integration-standard.adoc @@ -2,7 +2,7 @@ = Standard Annotation Support The following annotations are supported with standard semantics for all configurations of -the Spring TestContext Framework. Note that these annotations are not specific to tests +the Infra TestContext Framework. Note that these annotations are not specific to tests and can be used anywhere in the TODAY Framework. * `@Autowired` @@ -20,7 +20,7 @@ and can be used anywhere in the TODAY Framework. .JSR-250 Lifecycle Annotations [NOTE] ==== -In the Spring TestContext Framework, you can use `@PostConstruct` and `@PreDestroy` with +In the Infra TestContext Framework, you can use `@PostConstruct` and `@PreDestroy` with standard semantics on any application components configured in the `ApplicationContext`. However, these lifecycle annotations have limited usage within an actual test class. diff --git a/infra-docs/modules/ROOT/pages/testing/integration.adoc b/infra-docs/modules/ROOT/pages/testing/integration.adoc index fbddaa4b89..b66ab52ab4 100644 --- a/infra-docs/modules/ROOT/pages/testing/integration.adoc +++ b/infra-docs/modules/ROOT/pages/testing/integration.adoc @@ -10,25 +10,25 @@ Doing so lets you test things such as: of SQL statements, Hibernate queries, JPA entity mappings, and so forth. The TODAY Framework provides first-class support for integration testing in the -`spring-test` module. The name of the actual JAR file might include the release version +`today-test` module. The name of the actual JAR file might include the release version and might also be in the long `cn.taketoday.test` form, depending on where you get it from (see the xref:core/beans/dependencies.adoc[section on Dependency Management] for an explanation). This library includes the `cn.taketoday.test` package, which -contains valuable classes for integration testing with a Spring container. This testing +contains valuable classes for integration testing with a Infra container. This testing does not rely on an application server or other deployment environment. Such tests are slower to run than unit tests but much faster than the equivalent Selenium tests or remote tests that rely on deployment to an application server. Unit and integration testing support is provided in the form of the annotation-driven -xref:testing/testcontext-framework.adoc[Spring TestContext Framework]. The TestContext framework is +xref:testing/testcontext-framework.adoc[Infra TestContext Framework]. The TestContext framework is agnostic of the actual testing framework in use, which allows instrumentation of tests in various environments, including JUnit, TestNG, and others. -The following section provides an overview of the high-level goals of Spring's +The following section provides an overview of the high-level goals of Infra integration support, and the rest of this chapter then focuses on dedicated topics: * xref:testing/support-jdbc.adoc[JDBC Testing Support] -* xref:testing/testcontext-framework.adoc[Spring TestContext Framework] +* xref:testing/testcontext-framework.adoc[Infra TestContext Framework] * xref:testing/webtestclient.adoc[WebTestClient] * xref:testing/spring-mvc-test-framework.adoc[MockMvc] * xref:testing/spring-mvc-test-client.adoc[Testing Client Applications] @@ -39,12 +39,12 @@ integration support, and the rest of this chapter then focuses on dedicated topi [[integration-testing-goals]] == Goals of Integration Testing -Spring's integration testing support has the following primary goals: +Infra integration testing support has the following primary goals: * To manage xref:testing/integration.adoc#testing-ctx-management[Infra IoC container caching] between tests. * To provide xref:testing/integration.adoc#testing-fixture-di[Dependency Injection of test fixture instances]. * To provide xref:testing/integration.adoc#testing-tx[transaction management] appropriate to integration testing. -* To supply xref:testing/integration.adoc#testing-support-classes[Spring-specific base classes] that assist +* To supply xref:testing/integration.adoc#testing-support-classes[Infra-specific base classes] that assist developers in writing integration tests. The next few sections describe each goal and provide links to implementation and @@ -54,11 +54,11 @@ configuration details. [[testing-ctx-management]] === Context Management and Caching -The Spring TestContext Framework provides consistent loading of Spring +The Infra TestContext Framework provides consistent loading of Infra `ApplicationContext` instances and `WebApplicationContext` instances as well as caching of those contexts. Support for the caching of loaded contexts is important, because -startup time can become an issue -- not because of the overhead of Spring itself, but -because the objects instantiated by the Spring container take time to instantiate. For +startup time can become an issue -- not because of the overhead of Infra itself, but +because the objects instantiated by the Infra container take time to instantiate. For example, a project with 50 to 100 Hibernate mapping files might take 10 to 20 seconds to load the mapping files, and incurring that cost before running every test in every test fixture leads to slower overall test runs that reduce developer productivity. @@ -89,7 +89,7 @@ When the TestContext framework loads your application context, it can optionally configure instances of your test classes by using Dependency Injection. This provides a convenient mechanism for setting up test fixtures by using preconfigured beans from your application context. A strong benefit here is that you can reuse application contexts -across various testing scenarios (for example, for configuring Spring-managed object +across various testing scenarios (for example, for configuring Infra-managed object graphs, transactional proxies, `DataSource` instances, and others), thus avoiding the need to duplicate complex test fixture setup for individual test cases. @@ -97,7 +97,7 @@ As an example, consider a scenario where we have a class (`HibernateTitleReposit that implements data access logic for a `Title` domain entity. We want to write integration tests that test the following areas: -* The Spring configuration: Basically, is everything related to the configuration of the +* The Infra configuration: Basically, is everything related to the configuration of the `HibernateTitleRepository` bean correct and present? * The Hibernate mapping file configuration: Is everything mapped correctly and are the correct lazy-loading settings in place? @@ -136,7 +136,7 @@ See transaction management with the xref:testing/testcontext-framework/tx.adoc[T [[testing-support-classes]] === Support Classes for Integration Testing -The Spring TestContext Framework provides several `abstract` support classes that +The Infra TestContext Framework provides several `abstract` support classes that simplify the writing of integration tests. These base test classes provide well-defined hooks into the testing framework as well as convenient instance variables and methods, which let you access: @@ -145,7 +145,7 @@ which let you access: the context as a whole. * A `JdbcTemplate`, for executing SQL statements to query the database. You can use such queries to confirm database state both before and after execution of database-related - application code, and Spring ensures that such queries run in the scope of the same + application code, and Infra ensures that such queries run in the scope of the same transaction as the application code. When used in conjunction with an ORM tool, be sure to avoid xref:testing/testcontext-framework/tx.adoc#testcontext-tx-false-positives[false positives]. diff --git a/infra-docs/modules/ROOT/pages/testing/introduction.adoc b/infra-docs/modules/ROOT/pages/testing/introduction.adoc index f521a9813c..c7ac98391f 100644 --- a/infra-docs/modules/ROOT/pages/testing/introduction.adoc +++ b/infra-docs/modules/ROOT/pages/testing/introduction.adoc @@ -1,5 +1,5 @@ [[testing-introduction]] -= Introduction to Spring Testing += Introduction to Infra Testing :page-section-summary-toc: 1 Testing is an integral part of enterprise software development. This chapter focuses on diff --git a/infra-docs/modules/ROOT/pages/testing/resources.adoc b/infra-docs/modules/ROOT/pages/testing/resources.adoc index 473b619483..8ef9b65157 100644 --- a/infra-docs/modules/ROOT/pages/testing/resources.adoc +++ b/infra-docs/modules/ROOT/pages/testing/resources.adoc @@ -4,10 +4,10 @@ See the following resources for more information about testing: * https://www.junit.org/[JUnit]: "A programmer-friendly testing framework for Java and the JVM". Used by the TODAY Framework in its test suite and supported in the - xref:testing/testcontext-framework.adoc[Spring TestContext Framework]. + xref:testing/testcontext-framework.adoc[Infra TestContext Framework]. * https://testng.org/[TestNG]: A testing framework inspired by JUnit with added support for test groups, data-driven testing, distributed testing, and other features. Supported - in the xref:testing/testcontext-framework.adoc[Spring TestContext Framework] + in the xref:testing/testcontext-framework.adoc[Infra TestContext Framework] * {assertj-docs}[AssertJ]: "Fluent assertions for Java", including support for Java 8 lambdas, streams, and numerous other features. * https://en.wikipedia.org/wiki/Mock_Object[Mock Objects]: Article in Wikipedia. @@ -28,5 +28,3 @@ See the following resources for more information about testing: tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container. * https://sourceforge.net/projects/grinder/[The Grinder]: Java load testing framework. -* https://github.com/Ninja-Squad/springmockk[SpringMockK]: Support for Spring Boot - integration tests written in Kotlin using https://mockk.io/[MockK] instead of Mockito. diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-client.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-client.adoc index 44e7828f2b..1cd2714fab 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-client.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-client.adoc @@ -150,5 +150,5 @@ configuration. Check for the support for code completion on static members. == Further Examples of Client-side REST Tests Web MVC Test's own tests include -{today-framework-code}/spring-test/src/test/java/cn/taketoday/test/web/client/samples[example +{today-framework-code}/today-test/src/test/java/cn/taketoday/test/web/client/samples[example tests] of client-side REST tests. diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework.adoc index 61757ba8fa..b0f7dd8df6 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework.adoc @@ -2,7 +2,7 @@ = MockMvc :page-section-summary-toc: 1 -The Web MVC Test framework, also known as MockMvc, provides support for testing Spring +The Web MVC Test framework, also known as MockMvc, provides support for testing Infra MVC applications. It performs full Web MVC request handling but via mock request and response objects instead of a running server. diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-filters.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-filters.adoc index 878065f54b..ce7960ca0b 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-filters.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-filters.adoc @@ -10,7 +10,7 @@ instances, as the following example shows: mockMvc = standaloneSetup(new PersonController()).addFilters(new CharacterEncodingFilter()).build(); ---- -Registered filters are invoked through the `MockFilterChain` from `spring-test`, and the +Registered filters are invoked through the `MockFilterChain` from `today-test`, and the last filter delegates to the `DispatcherServlet`. diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit.adoc index 03895dfa44..3e1edb9754 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit.adoc @@ -2,7 +2,7 @@ = HtmlUnit Integration :page-section-summary-toc: 1 -Spring provides integration between xref:testing/spring-mvc-test-framework/server.adoc[MockMvc] and +Infra provides integration between xref:testing/spring-mvc-test-framework/server.adoc[MockMvc] and https://htmlunit.sourceforge.io/[HtmlUnit]. This simplifies performing end-to-end testing when using HTML-based views. This integration lets you: diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/mah.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/mah.adoc index fdef4719f6..b718606483 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/mah.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/mah.adoc @@ -55,9 +55,9 @@ to create a message, as the following example shows: ---- HtmlForm form = createMsgFormPage.getHtmlElementById("messageForm"); HtmlTextInput summaryInput = createMsgFormPage.getHtmlElementById("summary"); - summaryInput.setValueAttribute("Spring Rocks"); + summaryInput.setValueAttribute("Infra Rocks"); HtmlTextArea textInput = createMsgFormPage.getHtmlElementById("text"); - textInput.setText("In case you didn't know, Spring Rocks!"); + textInput.setText("In case you didn't know, Infra Rocks!"); HtmlSubmitInput submit = form.getOneHtmlElementByAttribute("input", "type", "submit"); HtmlPage newMessagePage = submit.click(); ---- diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc index ee099a5279..3e986ee26b 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-htmlunit/webdriver.adoc @@ -297,7 +297,7 @@ https://github.com/SeleniumHQ/selenium/wiki/Getting-Started[WebDriver documentat In the examples so far, we have used `MockMvcHtmlUnitDriverBuilder` in the simplest way possible, by building a `WebDriver` based on the `WebApplicationContext` loaded for us by -the Spring TestContext Framework. This approach is repeated here, as follows: +the Infra TestContext Framework. This approach is repeated here, as follows: [tabs] ====== @@ -326,7 +326,7 @@ WebDriver driver; @BeforeEach void setup() { driver = MockMvcHtmlUnitDriverBuilder - // demonstrates applying a MockMvcConfigurer (Spring Security) + // demonstrates applying a MockMvcConfigurer (Infra Security) .webAppContextSetup(context, springSecurity()) // for illustration only - defaults to "" .contextPath("") diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-resources.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-resources.adoc index 4627e18179..2b4140aa83 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-resources.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-resources.adoc @@ -3,9 +3,9 @@ :page-section-summary-toc: 1 The framework's own tests include -{today-framework-code}/spring-test/src/test/java/cn/taketoday/test/web/servlet/samples[ +{today-framework-code}/today-test/src/test/java/cn/taketoday/test/web/servlet/samples[ many sample tests] intended to show how to use MockMvc on its own or through the -{today-framework-code}/spring-test/src/test/java/cn/taketoday/test/web/servlet/samples/client[ +{today-framework-code}/today-test/src/test/java/cn/taketoday/test/web/servlet/samples/client[ WebTestClient]. Browse these examples for further ideas. diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-options.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-options.adoc index a8e06e0d07..1d944e2fc0 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-options.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-options.adoc @@ -3,7 +3,7 @@ MockMvc can be setup in one of two ways. One is to point directly to the controllers you want to test and programmatically configure Web MVC infrastructure. The second is to -point to Spring configuration with Web MVC and controller infrastructure in it. +point to Infra configuration with Web MVC and controller infrastructure in it. To set up MockMvc for testing a specific controller, use the following: @@ -27,11 +27,11 @@ Or you can also use this setup when testing through the xref:testing/webtestclient.adoc#webtestclient-controller-config[WebTestClient] which delegates to the same builder as shown above. -To set up MockMvc through Spring configuration, use the following: +To set up MockMvc through Infra configuration, use the following: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig(locations = "my-servlet-context.xml") +@JUnitWebConfig(locations = "my-servlet-context.xml") class MyWebTests { MockMvc mockMvc; @@ -55,9 +55,9 @@ as shown above. Which setup option should you use? The `webAppContextSetup` loads your actual Web MVC configuration, resulting in a more -complete integration test. Since the TestContext framework caches the loaded Spring +complete integration test. Since the TestContext framework caches the loaded Infra configuration, it helps keep tests running fast, even as you introduce more tests in your -test suite. Furthermore, you can inject mock services into controllers through Spring +test suite. Furthermore, you can inject mock services into controllers through Infra configuration to remain focused on testing the web layer. The following example declares a mock service with Mockito: @@ -73,7 +73,7 @@ expectations, as the following example shows: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig(locations = "test-servlet-context.xml") +@JUnitWebConfig(locations = "test-servlet-context.xml") class AccountTests { @Autowired @@ -93,8 +93,8 @@ class AccountTests { The `standaloneSetup`, on the other hand, is a little closer to a unit test. It tests one controller at a time. You can manually inject the controller with mock dependencies, and -it does not involve loading Spring configuration. Such tests are more focused on style -and make it easier to see which controller is being tested, whether any specific Spring +it does not involve loading Infra configuration. Such tests are more focused on style +and make it easier to see which controller is being tested, whether any specific Infra MVC configuration is required to work, and so on. The `standaloneSetup` is also a very convenient way to write ad-hoc tests to verify specific behavior or to debug an issue. diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-steps.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-steps.adoc index 792a6ac532..c79f247914 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-steps.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server-setup-steps.adoc @@ -18,7 +18,7 @@ MockMvc mockMvc = standaloneSetup(new MusicController()) ---- In addition, third-party frameworks (and applications) can pre-package setup -instructions, such as those in a `MockMvcConfigurer`. The Spring Framework has one such +instructions, such as those in a `MockMvcConfigurer`. The TODAY Framework has one such built-in implementation that helps to save and re-use the HTTP session across requests. You can use it as follows: diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server.adoc index f18a2af8a7..cdcd89f0c3 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/server.adoc @@ -12,7 +12,7 @@ The Web MVC Test framework, also known as `MockMvc`, aims to provide more comple testing for Web MVC controllers without a running server. It does that by invoking the `DispatcherServlet` and passing xref:testing/unit.adoc#mock-objects-servlet["`mock`" implementations of the Servlet API] from the -`spring-test` module which replicates the full Web MVC request handling without +`today-test` module which replicates the full Web MVC request handling without a running server. MockMvc is a server side test framework that lets you verify most of the functionality diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-end-to-end-integration-tests.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-end-to-end-integration-tests.adoc index 7dca1505c9..a16736d750 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-end-to-end-integration-tests.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-end-to-end-integration-tests.adoc @@ -2,7 +2,7 @@ = MockMvc vs End-to-End Tests MockMVc is built on Servlet API mock implementations from the -`spring-test` module and does not rely on a running container. Therefore, there are +`today-test` module and does not rely on a running container. Therefore, there are some differences when compared to full end-to-end integration tests with an actual client and a live server running. @@ -20,15 +20,15 @@ Thymeleaf and Freemarker, render HTML to the response body as expected. The same for rendering JSON, XML, and other formats through `@ResponseBody` methods. Alternatively, you may consider the full end-to-end integration testing support from -Spring Boot with `@SpringBootTest`. See the -{today-framework-reference}/spring-boot-features.html#boot-features-testing[Spring Boot Reference Guide]. +Infra App with `@InfraBootTest`. See the +{today-framework-reference}/spring-boot-features.html#boot-features-testing[Infra App Reference Guide]. There are pros and cons for each approach. The options provided in Web MVC Test are different stops on the scale from classic unit testing to full integration testing. To be certain, none of the options in Web MVC Test fall under the category of classic unit testing, but they are a little closer to it. For example, you can isolate the web layer by injecting mocked services into controllers, in which case you are testing the web -layer only through the `DispatcherServlet` but with actual Spring configuration, as you +layer only through the `DispatcherServlet` but with actual Infra configuration, as you might test the data access layer in isolation from the layers above it. Also, you can use the stand-alone setup, focusing on one controller at a time and manually providing the configuration required to make it work. diff --git a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-streaming-response.adoc b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-streaming-response.adoc index acf1b0b293..e05dada4ab 100644 --- a/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-streaming-response.adoc +++ b/infra-docs/modules/ROOT/pages/testing/spring-mvc-test-framework/vs-streaming-response.adoc @@ -27,7 +27,7 @@ StepVerifier.create(exchangeResult.getResponseBody()) ---- `WebTestClient` can also connect to a live server and perform full end-to-end integration -tests. This is also supported in Spring Boot where you can +tests. This is also supported in Infra App where you can {today-framework-reference}/spring-boot-features.html#boot-features-testing-spring-boot-applications-testing-with-running-server[test a running server]. diff --git a/infra-docs/modules/ROOT/pages/testing/support-jdbc.adoc b/infra-docs/modules/ROOT/pages/testing/support-jdbc.adoc index 0e2b4fce68..4e738cc1f6 100644 --- a/infra-docs/modules/ROOT/pages/testing/support-jdbc.adoc +++ b/infra-docs/modules/ROOT/pages/testing/support-jdbc.adoc @@ -19,8 +19,8 @@ methods. [TIP] ==== -xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4SpringContextTests`] -and xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGSpringContextTests`] +xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4InfraContextTests`] +and xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGInfraContextTests`] provide convenience methods that delegate to the aforementioned methods in `JdbcTestUtils`. ==== @@ -28,7 +28,7 @@ provide convenience methods that delegate to the aforementioned methods in [[integration-testing-support-jdbc-embedded-database]] == Embedded Databases -The `spring-jdbc` module provides support for configuring and launching an embedded +The `today-jdbc` module provides support for configuring and launching an embedded database, which you can use in integration tests that interact with a database. For details, see xref:data-access/jdbc/embedded-database-support.adoc[Embedded Database Support] and < class OrderServiceTests { diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/bootstrapping.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/bootstrapping.adoc index bf3be0e663..6bcbc40744 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/bootstrapping.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/bootstrapping.adoc @@ -1,12 +1,12 @@ [[testcontext-bootstrapping]] = Bootstrapping the TestContext Framework -The default configuration for the internals of the Spring TestContext Framework is +The default configuration for the internals of the Infra TestContext Framework is sufficient for all common use cases. However, there are times when a development team or third party framework would like to change the default `ContextLoader`, implement a custom `TestContext` or `ContextCache`, augment the default sets of `ContextCustomizerFactory` and `TestExecutionListener` implementations, and so on. For -such low-level control over how the TestContext framework operates, Spring provides a +such low-level control over how the TestContext framework operates, Infra provides a bootstrapping strategy. `TestContextBootstrapper` defines the SPI for bootstrapping the TestContext framework. A diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc index ba59ac6220..5131da7249 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management.adoc @@ -5,8 +5,8 @@ Each `TestContext` provides context management and caching support for the test for which it is responsible. Test instances do not automatically receive access to the configured `ApplicationContext`. However, if a test class implements the `ApplicationContextAware` interface, a reference to the `ApplicationContext` is supplied -to the test instance. Note that `AbstractJUnit4SpringContextTests` and -`AbstractTestNGSpringContextTests` implement `ApplicationContextAware` and, therefore, +to the test instance. Note that `AbstractJUnit4InfraContextTests` and +`AbstractTestNGInfraContextTests` implement `ApplicationContextAware` and, therefore, provide access to the `ApplicationContext` automatically. .@Autowired ApplicationContext @@ -22,7 +22,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig +@JUnitConfig class MyTest { @Autowired // <1> @@ -45,7 +45,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig // <1> +@JUnitWebConfig // <1> class MyWebAppTest { @Autowired // <2> @@ -73,7 +73,7 @@ context from a default location or default configuration classes. In addition to resource locations and component classes, an application context can also be configured through application context initializers. -The following sections explain how to use Spring's `@ContextConfiguration` annotation to +The following sections explain how to use Infra `@ContextConfiguration` annotation to configure a test `ApplicationContext` by using XML configuration files, Groovy scripts, component classes (typically `@Configuration` classes), or context initializers. Alternatively, you can implement and configure your own custom `SmartContextLoader` for diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc index e49be1c6e4..9ad480b94e 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/caching.adoc @@ -15,7 +15,7 @@ framework uses the following configuration parameters to build the context cache * `classes` (from `@ContextConfiguration`) * `contextInitializerClasses` (from `@ContextConfiguration`) * `contextCustomizers` (from `ContextCustomizerFactory`) – this includes - `@DynamicPropertySource` methods as well as various features from Spring Boot's + `@DynamicPropertySource` methods as well as various features from Infra App's testing support such as `@MockBean` and `@SpyBean`. * `contextLoader` (from `@ContextConfiguration`) * `parent` (from `@ContextHierarchy`) @@ -39,7 +39,7 @@ faster. .Test suites and forked processes [NOTE] ==== -The Spring TestContext framework stores application contexts in a static cache. This +The Infra TestContext framework stores application contexts in a static cache. This means that the context is literally stored in a `static` variable. In other words, if tests run in separate processes, the static cache is cleared between each test execution, which effectively disables the caching mechanism. @@ -60,7 +60,7 @@ maximum size is reached, a least recently used (LRU) eviction policy is used to close stale contexts. You can configure the maximum size from the command line or a build script by setting a JVM system property named `spring.test.context.cache.maxSize`. As an alternative, you can set the same property via the -xref:appendix.adoc#appendix-infra-properties[`SpringProperties`] mechanism. +xref:appendix.adoc#appendix-infra-properties[`InfraProperties`] mechanism. Since having a large number of application contexts loaded within a given test suite can cause the suite to take an unnecessarily long time to run, it is often beneficial to @@ -71,8 +71,8 @@ the underlying context cache, you can set the log level for the In the unlikely case that a test corrupts the application context and requires reloading (for example, by modifying a bean definition or the state of an application object), you can annotate your test class or test method with `@DirtiesContext` (see the discussion of -`@DirtiesContext` in xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[Spring Testing Annotations] -). This instructs Spring to remove the context from the cache and rebuild +`@DirtiesContext` in xref:testing/annotations/integration-spring/annotation-dirtiescontext.adoc[Infra Testing Annotations] +). This instructs Infra to remove the context from the cache and rebuild the application context before running the next test that requires the same application context. Note that support for the `@DirtiesContext` annotation is provided by the `DirtiesContextBeforeModesTestExecutionListener` and the @@ -81,14 +81,14 @@ context. Note that support for the `@DirtiesContext` annotation is provided by t .ApplicationContext lifecycle and console logging [NOTE] ==== -When you need to debug a test executed with the Spring TestContext Framework, it can be +When you need to debug a test executed with the Infra TestContext Framework, it can be useful to analyze the console output (that is, output to the `SYSOUT` and `SYSERR` streams). Some build tools and IDEs are able to associate console output with a given test; however, some console output cannot be easily associated with a given test. -With regard to console logging triggered by the Spring Framework itself or by components +With regard to console logging triggered by the TODAY Framework itself or by components registered in the `ApplicationContext`, it is important to understand the lifecycle of an -`ApplicationContext` that has been loaded by the Spring TestContext Framework within a +`ApplicationContext` that has been loaded by the Infra TestContext Framework within a test suite. The `ApplicationContext` for a test is typically loaded when an instance of the test diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/context-customizers.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/context-customizers.adoc index 9f408d0138..8b6594c93a 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/context-customizers.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/context-customizers.adoc @@ -11,7 +11,7 @@ test class -- for example, based on the presence of a certain annotation. Factor invoked after `ContextLoaders` have processed context configuration attributes for a test class but before the `MergedContextConfiguration` is created. -For example, Spring Framework provides the following `ContextCustomizerFactory` +For example, TODAY Framework provides the following `ContextCustomizerFactory` implementation which is registered by default: `MockServerContainerContextCustomizerFactory`:: Creates a @@ -40,14 +40,14 @@ Registering `ContextCustomizerFactory` implementations by using `@ContextCustomi suitable for custom factories that are used in limited testing scenarios. However, it can become cumbersome if a custom factory needs to be used across an entire test suite. This issue is addressed through support for automatic discovery of default -`ContextCustomizerFactory` implementations through the `SpringFactoriesLoader` mechanism. +`ContextCustomizerFactory` implementations through the `InfraFactoriesLoader` mechanism. -For example, the modules that make up the testing support in Spring Framework and Spring +For example, the modules that make up the testing support in TODAY Framework and Infra Boot declare all core default `ContextCustomizerFactory` implementations under the `cn.taketoday.test.context.ContextCustomizerFactory` key in their `META-INF/spring.factories` properties files. The `spring.factories` file for the -`spring-test` module can be viewed -{today-framework-code}/spring-test/src/main/resources/META-INF/spring.factories[here]. +`today-test` module can be viewed +{today-framework-code}/today-test/src/main/resources/META-INF/spring.factories[here]. Third-party frameworks and developers can contribute their own `ContextCustomizerFactory` implementations to the list of default factories in the same manner through their own `spring.factories` files. diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc index cf4fcd476e..f71c78b608 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/dynamic-property-sources.adoc @@ -1,7 +1,7 @@ [[testcontext-ctx-management-dynamic-property-sources]] = Context Configuration with Dynamic Property Sources -As of Spring Framework 5.2.5, the TestContext framework provides support for _dynamic_ +As of TODAY Framework 5.2.5, the TestContext framework provides support for _dynamic_ properties via the `@DynamicPropertySource` annotation. This annotation can be used in integration tests that need to add properties with dynamic values to the set of `PropertySources` in the `Environment` for the `ApplicationContext` loaded for the @@ -12,7 +12,7 @@ integration test. The `@DynamicPropertySource` annotation and its supporting infrastructure were originally designed to allow properties from {testcontainers-site}[Testcontainers] based tests to be exposed easily to -Spring integration tests. However, this feature may also be used with any form of +Infra integration tests. However, this feature may also be used with any form of external resource whose lifecycle is maintained outside the test's `ApplicationContext`. ==== @@ -22,11 +22,11 @@ to a `static` method that accepts a single `DynamicPropertyRegistry` argument wh used to add _name-value_ pairs to the `Environment`. Values are dynamic and provided via a `Supplier` which is only invoked when the property is resolved. Typically, method references are used to supply values, as can be seen in the following example which uses -the Testcontainers project to manage a Redis container outside of the Spring +the Testcontainers project to manage a Redis container outside of the Infra `ApplicationContext`. The IP address and port of the managed Redis container are made available to components within the test's `ApplicationContext` via the `redis.host` and -`redis.port` properties. These properties can be accessed via Spring's `Environment` -abstraction or injected directly into Spring-managed components – for example, via +`redis.port` properties. These properties can be accessed via Infra `Environment` +abstraction or injected directly into Infra-managed components – for example, via `@Value("${redis.host}")` and `@Value("${redis.port}")`, respectively. [TIP] @@ -40,7 +40,7 @@ properties. [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(/* ... */) +@JUnitConfig(/* ... */) @Testcontainers class ExampleIntegrationTests { diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc index da072b026b..2cdd90c030 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/env-profiles.adoc @@ -60,7 +60,7 @@ Consider two examples with XML configuration and `@Configuration` classes: ---- [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from "classpath:/app-config.xml" @ContextConfiguration("/app-config.xml") @ActiveProfiles("dev") @@ -83,7 +83,7 @@ When `TransferServiceTest` is run, its `ApplicationContext` is loaded from the `dataSource` is defined three times: in the `production` profile, in the `dev` profile, and in the `default` profile. -By annotating `TransferServiceTest` with `@ActiveProfiles("dev")`, we instruct the Spring +By annotating `TransferServiceTest` with `@ActiveProfiles("dev")`, we instruct the Infra TestContext Framework to load the `ApplicationContext` with the active profiles set to `{"dev"}`. As a result, an embedded database is created and populated with test data, and the `accountRepository` bean is wired with a reference to the development `DataSource`. @@ -171,7 +171,7 @@ public class TransferServiceConfig { [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig({ +@JUnitConfig({ TransferServiceConfig.class, StandaloneDataConfig.class, JndiDataConfig.class, @@ -213,12 +213,12 @@ automatically inherit the `@ActiveProfiles` configuration from the base class. I following example, the declaration of `@ActiveProfiles` (as well as other annotations) has been moved to an abstract superclass, `AbstractIntegrationTest`: -NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing +NOTE: As of TODAY Framework 5.3, test configuration may also be inherited from enclosing classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details. [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig({ +@JUnitConfig({ TransferServiceConfig.class, StandaloneDataConfig.class, JndiDataConfig.class, diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/failure-threshold.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/failure-threshold.adoc index cd6fddc350..66d210b498 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/failure-threshold.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/failure-threshold.adoc @@ -1,7 +1,7 @@ [[testcontext-ctx-management-failure-threshold]] = Context Failure Threshold -As of Spring Framework 6.1, a context _failure threshold_ policy is in place which helps +As of TODAY Framework 6.1, a context _failure threshold_ policy is in place which helps avoid repeated attempts to load a failing `ApplicationContext`. By default, the failure threshold is set to `1` which means that only one attempt will be made to load an `ApplicationContext` for a given context cache key (see @@ -16,7 +16,7 @@ external resource that prevents the context from loading in the current environm You can configure the context failure threshold from the command line or a build script by setting a JVM system property named `spring.test.context.failure.threshold` with a positive integer value. As an alternative, you can set the same property via the -xref:appendix.adoc#appendix-infra-properties[`SpringProperties`] mechanism. +xref:appendix.adoc#appendix-infra-properties[`InfraProperties`] mechanism. NOTE: If you wish to effectively disable the context failure threshold, you can set the property to a very large value. For example, from the command line you could set the diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc index 6dc1b58b9b..b61beef0b9 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/groovy.adoc @@ -9,14 +9,14 @@ lookup semantics for Groovy scripts are the same as those described for xref:testing/testcontext-framework/ctx-management/xml.adoc[XML configuration files]. .Enabling Groovy script support -TIP: Support for using Groovy scripts to load an `ApplicationContext` in the Spring +TIP: Support for using Groovy scripts to load an `ApplicationContext` in the Infra TestContext Framework is enabled automatically if Groovy is on the classpath. The following example shows how to specify Groovy configuration files: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from "/AppConfig.groovy" and // "/TestConfig.groovy" in the root of the classpath @ContextConfiguration({"/AppConfig.groovy", "/TestConfig.Groovy"}) <1> @@ -37,7 +37,7 @@ the default: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from // "classpath:com/example/MyTestContext.groovy" @ContextConfiguration // <1> @@ -61,7 +61,7 @@ The following listing shows how to combine both in an integration test: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from // "/app-config.xml" and "/TestConfig.groovy" @ContextConfiguration({ "/app-config.xml", "/TestConfig.groovy" }) diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/hierarchies.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/hierarchies.adoc index 9ddee7b321..9dcbfbab89 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/hierarchies.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/hierarchies.adoc @@ -1,15 +1,15 @@ [[testcontext-ctx-management-ctx-hierarchies]] = Context Hierarchies -When writing integration tests that rely on a loaded Spring `ApplicationContext`, it is +When writing integration tests that rely on a loaded Infra `ApplicationContext`, it is often sufficient to test against a single context. However, there are times when it is beneficial or even necessary to test against a hierarchy of `ApplicationContext` instances. For example, if you are developing a Web MVC web application, you typically -have a root `WebApplicationContext` loaded by Spring's `ContextLoaderListener` and a -child `WebApplicationContext` loaded by Spring's `DispatcherServlet`. This results in a +have a root `WebApplicationContext` loaded by Infra `ContextLoaderListener` and a +child `WebApplicationContext` loaded by Infra `DispatcherServlet`. This results in a parent-child context hierarchy where shared components and infrastructure configuration are declared in the root context and consumed in the child context by web-specific -components. Another use case can be found in Spring Batch applications, where you often +components. Another use case can be found in Infra Batch applications, where you often have a parent context that provides configuration for shared batch infrastructure and a child context for the configuration of a specific batch job. @@ -37,7 +37,7 @@ lowest context in the hierarchy). The following listing shows this configuration [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) @WebAppConfiguration @ContextHierarchy({ @ContextConfiguration(classes = TestAppConfig.class), @@ -58,7 +58,7 @@ class ControllerIntegrationTests { -- The test classes in this example define a context hierarchy within a test class hierarchy. `AbstractWebTests` declares the configuration for a root -`WebApplicationContext` in a Spring-powered web application. Note, however, that +`WebApplicationContext` in a Infra-powered web application. Note, however, that `AbstractWebTests` does not declare `@ContextHierarchy`. Consequently, subclasses of `AbstractWebTests` can optionally participate in a context hierarchy or follow the standard semantics for `@ContextConfiguration`. `SoapWebServiceTests` and @@ -71,7 +71,7 @@ configuration scenario: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- - @ExtendWith(SpringExtension.class) + @ExtendWith(InfraExtension.class) @WebAppConfiguration @ContextConfiguration("file:src/main/webapp/WEB-INF/applicationContext.xml") public abstract class AbstractWebTests {} @@ -90,7 +90,7 @@ configuration scenario: The classes in this example show the use of named hierarchy levels in order to merge the configuration for specific levels in a context hierarchy. `BaseTests` defines two levels in the hierarchy, `parent` and `child`. `ExtendedTests` extends `BaseTests` and instructs -the Spring TestContext Framework to merge the context configuration for the `child` +the Infra TestContext Framework to merge the context configuration for the `child` hierarchy level, by ensuring that the names declared in the `name` attribute in `@ContextConfiguration` are both `child`. The result is that three application contexts are loaded: one for `/app-config.xml`, one for `/user-config.xml`, and one for diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc index ebcf9d7b62..a197491611 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/inheritance.adoc @@ -29,7 +29,7 @@ another and use both its own configuration file and the superclass's configurati [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from "/base-config.xml" // in the root of the classpath @ContextConfiguration("/base-config.xml") <1> @@ -61,13 +61,13 @@ Java:: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- // ApplicationContext will be loaded from BaseConfig -@SpringJUnitConfig(BaseConfig.class) // <1> +@JUnitConfig(BaseConfig.class) // <1> class BaseTest { // class body... } // ApplicationContext will be loaded from BaseConfig and ExtendedConfig -@SpringJUnitConfig(ExtendedConfig.class) // <2> +@JUnitConfig(ExtendedConfig.class) // <2> class ExtendedTest extends BaseTest { // class body... } @@ -80,21 +80,21 @@ class ExtendedTest extends BaseTest { In the next example, which uses context initializers, the `ApplicationContext` for `ExtendedTest` is initialized by using `BaseInitializer` and `ExtendedInitializer`. Note, however, that the order in which the initializers are invoked depends on whether they -implement Spring's `Ordered` interface or are annotated with Spring's `@Order` annotation +implement Infra `Ordered` interface or are annotated with Infra `@Order` annotation or the standard `@Priority` annotation. The following example shows how one class can extend another and use both its own initializer and the superclass's initializer: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- // ApplicationContext will be initialized by BaseInitializer -@SpringJUnitConfig(initializers = BaseInitializer.class) // <1> +@JUnitConfig(initializers = BaseInitializer.class) // <1> class BaseTest { // class body... } // ApplicationContext will be initialized by BaseInitializer // and ExtendedInitializer -@SpringJUnitConfig(initializers = ExtendedInitializer.class) // <2> +@JUnitConfig(initializers = ExtendedInitializer.class) // <2> class ExtendedTest extends BaseTest { // class body... } diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/initializers.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/initializers.adoc index cd9dff820b..367568f0e2 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/initializers.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/initializers.adoc @@ -9,13 +9,13 @@ initialize the `ConfigurableApplicationContext` that is loaded for your tests. N the concrete `ConfigurableApplicationContext` type supported by each declared initializer must be compatible with the type of `ApplicationContext` created by the `SmartContextLoader` in use (typically a `GenericApplicationContext`). Furthermore, the -order in which the initializers are invoked depends on whether they implement Spring's -`Ordered` interface or are annotated with Spring's `@Order` annotation or the standard +order in which the initializers are invoked depends on whether they implement Infra +`Ordered` interface or are annotated with Infra `@Order` annotation or the standard `@Priority` annotation. The following example shows how to use initializers: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from TestConfig // and initialized by TestAppCtxInitializer @ContextConfiguration( @@ -36,7 +36,7 @@ files or configuration classes. The following example shows how to do so: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be initialized by EntireAppInitializer // which presumably registers beans in the context @ContextConfiguration(initializers = EntireAppInitializer.class) <1> diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/javaconfig.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/javaconfig.adoc index 00951cd461..067487c245 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/javaconfig.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/javaconfig.adoc @@ -8,7 +8,7 @@ that contains references to component classes. The following example shows how t [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from AppConfig and TestConfig @ContextConfiguration(classes = {AppConfig.class, TestConfig.class}) // <1> class MyTest { @@ -28,9 +28,9 @@ The term "`component class`" can refer to any of the following: * A component (that is, a class annotated with `@Component`, `@Service`, `@Repository`, or other stereotype annotations). * A JSR-330 compliant class that is annotated with `jakarta.inject` annotations. * Any class that contains `@Bean`-methods. -* Any other class that is intended to be registered as a Spring component (i.e., a Spring +* Any other class that is intended to be registered as a Infra component (i.e., a Infra bean in the `ApplicationContext`), potentially taking advantage of automatic autowiring - of a single constructor without the use of Spring annotations. + of a single constructor without the use of Infra annotations. See the javadoc of {today-framework-api}/context/annotation/Configuration.html[`@Configuration`] and @@ -53,7 +53,7 @@ class: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig <1> +@JUnitConfig <1> // ApplicationContext will be loaded from the static nested Config class class OrderServiceTest { diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc index c1b97b4a7a..8bf249e3d1 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/mixed-config.adoc @@ -5,14 +5,14 @@ It may sometimes be desirable to mix XML configuration files, Groovy scripts, an component classes (typically `@Configuration` classes) to configure an `ApplicationContext` for your tests. For example, if you use XML configuration in production, you may decide that you want to use `@Configuration` classes to configure -specific Spring-managed components for your tests, or vice versa. +specific Infra-managed components for your tests, or vice versa. -Furthermore, some third-party frameworks (such as Spring Boot) provide first-class +Furthermore, some third-party frameworks (such as Infra App) provide first-class support for loading an `ApplicationContext` from different types of resources simultaneously (for example, XML configuration files, Groovy scripts, and -`@Configuration` classes). The Spring Framework, historically, has not supported this for +`@Configuration` classes). The TODAY Framework, historically, has not supported this for standard deployments. Consequently, most of the `SmartContextLoader` implementations that -the Spring Framework delivers in the `spring-test` module support only one resource type +the TODAY Framework delivers in the `today-test` module support only one resource type for each test context. However, this does not mean that you cannot use both. One exception to the general rule is that the `GenericGroovyXmlContextLoader` and `GenericGroovyXmlWebContextLoader` support both XML configuration files and Groovy @@ -23,7 +23,7 @@ the standard testing support in the TestContext framework, you have the followin If you want to use resource locations (for example, XML or Groovy) and `@Configuration` classes to configure your tests, you must pick one as the entry point, and that one must include or import the other. For example, in XML or Groovy scripts, you can include -`@Configuration` classes by using component scanning or defining them as normal Spring +`@Configuration` classes by using component scanning or defining them as normal Infra beans, whereas, in a `@Configuration` class, you can use `@ImportResource` to import XML configuration files or Groovy scripts. Note that this behavior is semantically equivalent to how you configure your application in production: In production configuration, you diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc index 8af4f76d68..86bd319743 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/property-sources.adoc @@ -1,7 +1,7 @@ [[testcontext-ctx-management-property-sources]] = Context Configuration with Test Property Sources -The Spring Framework has first-class support for the notion of an environment with a +The TODAY Framework has first-class support for the notion of an environment with a hierarchy of property sources, and you can configure integration tests with test-specific property sources. In contrast to the `@PropertySource` annotation used on `@Configuration` classes, you can declare the `@TestPropertySource` annotation on a test @@ -28,11 +28,11 @@ You can configure test properties files by using the `locations` or `value` attr By default, both traditional and XML-based `java.util.Properties` file formats are supported -- for example, `"classpath:/com/example/test.properties"` or -`"file:///path/to/file.xml"`. As of Spring Framework 6.1, you can configure a custom +`"file:///path/to/file.xml"`. As of TODAY Framework 6.1, you can configure a custom `PropertySourceFactory` via the `factory` attribute in `@TestPropertySource` in order to support a different file format such as JSON, YAML, etc. -Each path is interpreted as a Spring `Resource`. A plain path (for example, +Each path is interpreted as a Infra `Resource`. A plain path (for example, `"test.properties"`) is treated as a classpath resource that is relative to the package in which the test class is defined. A path starting with a slash is treated as an absolute classpath resource (for example: `"/org/example/test.xml"`). A path that @@ -41,7 +41,7 @@ loaded by using the specified resource protocol. Property placeholders in paths (such as `${...}`) will be resolved against the `Environment`. -As of Spring Framework 6.1, resource location patterns are also supported — for +As of TODAY Framework 6.1, resource location patterns are also supported — for example, `"classpath*:/config/*.properties"`. The following example uses a test properties file: @@ -107,7 +107,7 @@ class MyIntegrationTests { ====== -As of Spring Framework 6.1, you can use _text blocks_ to define multiple inlined +As of TODAY Framework 6.1, you can use _text blocks_ to define multiple inlined properties in a single `String`. The following example sets two inlined properties using a text block: @@ -127,7 +127,7 @@ class MyIntegrationTests { [NOTE] ==== -As of Spring Framework 5.2, `@TestPropertySource` can be used as _repeatable annotation_. +As of TODAY Framework 5.2, `@TestPropertySource` can be used as _repeatable annotation_. That means that you can have multiple declarations of `@TestPropertySource` on a single test class, with the `locations` and `properties` from later `@TestPropertySource` annotations overriding those from previous `@TestPropertySource` annotations. @@ -208,7 +208,7 @@ If the `inheritLocations` or `inheritProperties` attribute in `@TestPropertySour set to `false`, the locations or inlined properties, respectively, for the test class shadow and effectively replace the configuration defined by superclasses. -NOTE: As of Spring Framework 5.3, test configuration may also be inherited from enclosing +NOTE: As of TODAY Framework 5.3, test configuration may also be inherited from enclosing classes. See xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-nested-test-configuration[`@Nested` test class configuration] for details. In the next example, the `ApplicationContext` for `BaseTest` is loaded by using only the diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web-mocks.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web-mocks.adoc index 93efa23422..2e8a49ffe4 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web-mocks.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web-mocks.adoc @@ -4,7 +4,7 @@ To provide comprehensive web testing support, the TestContext framework has a `ServletTestExecutionListener` that is enabled by default. When testing against a `WebApplicationContext`, this xref:testing/testcontext-framework/key-abstractions.adoc[`TestExecutionListener`] -sets up default thread-local state by using Spring Web's `RequestContextHolder` before +sets up default thread-local state by using Infra Web's `RequestContextHolder` before each test method and creates a `MockHttpServletRequest`, a `MockHttpServletResponse`, and a `ServletWebRequest` based on the base resource path configured with `@WebAppConfiguration`. `ServletTestExecutionListener` also ensures that the @@ -24,7 +24,7 @@ Injecting mocks:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig +@JUnitWebConfig class WacTests { @Autowired diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web.adoc index b7ac196c1a..2088f9cf2c 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/web.adoc @@ -16,9 +16,9 @@ directory structure of a web application in a Maven project, you know that override this default, you can provide an alternate path to the `@WebAppConfiguration` annotation (for example, `@WebAppConfiguration("src/test/webapp")`). If you wish to reference a base resource path from the classpath instead of the file system, you can use -Spring's `classpath:` prefix. +Infra `classpath:` prefix. -Note that Spring's testing support for `WebApplicationContext` implementations is on par +Note that Infra testing support for `WebApplicationContext` implementations is on par with its support for standard `ApplicationContext` implementations. When testing with a `WebApplicationContext`, you are free to declare XML configuration files, Groovy scripts, or `@Configuration` classes by using `@ContextConfiguration`. You are also free to use @@ -35,7 +35,7 @@ Conventions:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // defaults to "file:src/main/webapp" @WebAppConfiguration @@ -53,7 +53,7 @@ class WacTests { If you annotate a test class with `@WebAppConfiguration` without specifying a resource base path, the resource path effectively defaults to `file:src/main/webapp`. Similarly, if you declare `@ContextConfiguration` without specifying resource `locations`, component -`classes`, or context `initializers`, Spring tries to detect the presence of your +`classes`, or context `initializers`, Infra tries to detect the presence of your configuration by using conventions (that is, `WacTests-context.xml` in the same package as the `WacTests` class or static nested `@Configuration` classes). @@ -66,7 +66,7 @@ Default resource semantics:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // file system resource @WebAppConfiguration("webapp") @@ -85,7 +85,7 @@ annotations. By default, `@WebAppConfiguration` resource paths are file system b whereas `@ContextConfiguration` resource locations are classpath based. The following example shows that we can override the default resource semantics for both -annotations by specifying a Spring resource prefix: +annotations by specifying a Infra resource prefix: [tabs] ====== @@ -93,7 +93,7 @@ Explicit resource semantics:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // classpath resource @WebAppConfiguration("classpath:test-web-resources") diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/xml.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/xml.adoc index 4724a8b613..37f2e225c1 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/xml.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/ctx-management/xml.adoc @@ -16,7 +16,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from "/app-config.xml" and // "/test-config.xml" in the root of the classpath @ContextConfiguration(locations = {"/app-config.xml", "/test-config.xml"}) // <1> @@ -41,7 +41,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) @ContextConfiguration({"/app-config.xml", "/test-config.xml"}) <1> class MyTest { // class body... @@ -65,7 +65,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) // ApplicationContext will be loaded from // "classpath:com/example/MyTest-context.xml" @ContextConfiguration // <1> diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc index e77b168c91..48ef0409f4 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/executing-sql.adoc @@ -3,8 +3,8 @@ When writing integration tests against a relational database, it is often beneficial to run SQL scripts to modify the database schema or insert test data into tables. The -`spring-jdbc` module provides support for _initializing_ an embedded or existing database -by executing SQL scripts when the Spring `ApplicationContext` is loaded. See +`today-jdbc` module provides support for _initializing_ an embedded or existing database +by executing SQL scripts when the Infra `ApplicationContext` is loaded. See xref:data-access/jdbc/embedded-database-support.adoc[Embedded database support] and xref:data-access/jdbc/embedded-database-support.adoc#jdbc-embedded-database-dao-testing[Testing data access logic with an embedded database] for details. @@ -17,13 +17,13 @@ scripts programmatically and declaratively during integration tests. [[testcontext-executing-sql-programmatically]] == Executing SQL scripts programmatically -Spring provides the following options for executing SQL scripts programmatically within +Infra provides the following options for executing SQL scripts programmatically within integration test methods. * `cn.taketoday.jdbc.datasource.init.ScriptUtils` * `cn.taketoday.jdbc.datasource.init.ResourceDatabasePopulator` -* `cn.taketoday.test.context.junit4.AbstractTransactionalJUnit4SpringContextTests` -* `cn.taketoday.test.context.testng.AbstractTransactionalTestNGSpringContextTests` +* `cn.taketoday.test.context.junit4.AbstractTransactionalJUnit4InfraContextTests` +* `cn.taketoday.test.context.testng.AbstractTransactionalTestNGInfraContextTests` `ScriptUtils` provides a collection of static utility methods for working with SQL scripts and is mainly intended for internal use within the framework. However, if you @@ -68,8 +68,8 @@ void databaseTest() { Note that `ResourceDatabasePopulator` internally delegates to `ScriptUtils` for parsing and running SQL scripts. Similarly, the `executeSqlScript(..)` methods in -xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4SpringContextTests`] -and xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGSpringContextTests`] +xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4InfraContextTests`] +and xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGInfraContextTests`] internally use a `ResourceDatabasePopulator` to run SQL scripts. See the Javadoc for the various `executeSqlScript(..)` methods for further details. @@ -77,7 +77,7 @@ various `executeSqlScript(..)` methods for further details. == Executing SQL scripts declaratively with @Sql In addition to the aforementioned mechanisms for running SQL scripts programmatically, -you can declaratively configure SQL scripts in the Spring TestContext Framework. +you can declaratively configure SQL scripts in the Infra TestContext Framework. Specifically, you can declare the `@Sql` annotation on a test class or test method to configure individual SQL statements or the resource paths to SQL scripts that should be run against a given database before or after an integration test class or test method. @@ -100,7 +100,7 @@ in addition to any method-level scripts and statements. [[testcontext-executing-sql-declaratively-script-resources]] === Path Resource Semantics -Each path is interpreted as a Spring `Resource`. A plain path (for example, +Each path is interpreted as a Infra `Resource`. A plain path (for example, `"schema.sql"`) is treated as a classpath resource that is relative to the package in which the test class is defined. A path starting with a slash is treated as an absolute classpath resource (for example, `"/org/example/schema.sql"`). A path that references a @@ -116,7 +116,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig +@JUnitConfig @Sql("/test-schema.sql") class DatabaseTests { @@ -243,7 +243,7 @@ void userTest() { NOTE: `ISOLATED` and `AFTER_TEST_METHOD` are statically imported from `Sql.TransactionMode` and `Sql.ExecutionPhase`, respectively. -As of Spring Framework 6.1, it is possible to run a particular set of scripts before or +As of TODAY Framework 6.1, it is possible to run a particular set of scripts before or after the test class by setting the `executionPhase` attribute in a class-level `@Sql` declaration to `BEFORE_TEST_CLASS` or `AFTER_TEST_CLASS`, as the following example shows: @@ -253,7 +253,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig +@JUnitConfig @Sql(scripts = "/test-schema.sql", executionPhase = BEFORE_TEST_CLASS) class DatabaseTests { @@ -305,7 +305,7 @@ individual attributes in {today-framework-api}/test/context/jdbc/Sql.html[`@Sql` By default, the `SqlScriptsTestExecutionListener` infers the desired transaction semantics for scripts configured by using `@Sql`. Specifically, SQL scripts are run -without a transaction, within an existing Spring-managed transaction (for example, a +without a transaction, within an existing Infra-managed transaction (for example, a transaction managed by the `TransactionalTestExecutionListener` for a test annotated with `@Transactional`), or within an isolated transaction, depending on the configured value of the `transactionMode` attribute in `@SqlConfig` and the presence of a @@ -331,7 +331,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestDatabaseConfig.class) +@JUnitConfig(TestDatabaseConfig.class) @Transactional class TransactionalSqlScriptsTests { @@ -372,7 +372,7 @@ details). [[testcontext-executing-sql-declaratively-script-merging]] === Merging and Overriding Configuration with `@SqlMergeMode` -As of Spring Framework 5.2, it is possible to merge method-level `@Sql` declarations with +As of TODAY Framework 5.2, it is possible to merge method-level `@Sql` declarations with class-level declarations. For example, this allows you to provide the configuration for a database schema or some common test data once per test class and then provide additional, use case specific test data per test method. To enable `@Sql` merging, annotate either diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/fixture-di.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/fixture-di.adoc index 2dceae084d..8dc4997af2 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/fixture-di.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/fixture-di.adoc @@ -7,8 +7,8 @@ application context that you configured with `@ContextConfiguration` or related annotations. You may use setter injection, field injection, or both, depending on which annotations you choose and whether you place them on setter methods or fields. If you are using JUnit Jupiter you may also optionally use constructor injection -(see xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-di[Dependency Injection with `SpringExtension`]). For consistency with Spring's annotation-based -injection support, you may also use Spring's `@Autowired` annotation or the `@Inject` +(see xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-di[Dependency Injection with `InfraExtension`]). For consistency with Infra annotation-based +injection support, you may also use Infra `@Autowired` annotation or the `@Inject` annotation from JSR-330 for field and setter injection. TIP: For testing frameworks other than JUnit Jupiter, the TestContext framework does not @@ -60,8 +60,8 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) -// specifies the Spring configuration to load for this test fixture +@ExtendWith(InfraExtension.class) +// specifies the Infra configuration to load for this test fixture @ContextConfiguration("repository-config.xml") class HibernateTitleRepositoryTests { @@ -88,8 +88,8 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) -// specifies the Spring configuration to load for this test fixture +@ExtendWith(InfraExtension.class) +// specifies the Infra configuration to load for this test fixture @ContextConfiguration("repository-config.xml") class HibernateTitleRepositoryTests { @@ -137,7 +137,7 @@ shows this configuration: [NOTE] ===== -If you are extending from a Spring-provided test base class that happens to use +If you are extending from a Infra-provided test base class that happens to use `@Autowired` on one of its setter methods, you might have multiple beans of the affected type defined in your application context (for example, multiple `DataSource` beans). In such a case, you can override the setter method and use the `@Qualifier` annotation to diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/key-abstractions.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/key-abstractions.adoc index 3081878907..8da36b845d 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/key-abstractions.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/key-abstractions.adoc @@ -11,7 +11,7 @@ and delegates to `TestExecutionListener` implementations, which instrument the a test execution by providing dependency injection, managing transactions, and so on. A `SmartContextLoader` is responsible for loading an `ApplicationContext` for a given test class. See the {today-framework-api}/test/context/package-summary.html[javadoc] and the -Spring test suite for further information and examples of various implementations. +Infra test suite for further information and examples of various implementations. [[testcontext]] == `TestContext` @@ -24,7 +24,7 @@ the test instance for which it is responsible. The `TestContext` also delegates [[testcontextmanager]] == `TestContextManager` -`TestContextManager` is the main entry point into the Spring TestContext Framework and is +`TestContextManager` is the main entry point into the Infra TestContext Framework and is responsible for managing a single `TestContext` and signaling events to each registered `TestExecutionListener` at well-defined test execution points: @@ -46,7 +46,7 @@ the `TestContextManager` with which the listener is registered. See xref:testing == Context Loaders `ContextLoader` is a strategy interface for loading an `ApplicationContext` for an -integration test managed by the Spring TestContext Framework. You should implement +integration test managed by the Infra TestContext Framework. You should implement `SmartContextLoader` instead of this interface to provide support for component classes, active bean definition profiles, test property sources, context hierarchies, and `WebApplicationContext` support. @@ -57,7 +57,7 @@ process resource locations, component classes, or context initializers. Furtherm `SmartContextLoader` can set active bean definition profiles and test property sources in the context that it loads. -Spring provides the following implementations: +Infra provides the following implementations: * `DelegatingSmartContextLoader`: One of two default loaders, it delegates internally to an `AnnotationConfigContextLoader`, a `GenericXmlContextLoader`, or a diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc index 552f4a768b..6dbe774c95 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/parallel-test-execution.adoc @@ -1,8 +1,8 @@ [[testcontext-parallel-test-execution]] = Parallel Test Execution -Spring Framework 5.0 introduced basic support for executing tests in parallel within a -single JVM when using the Spring TestContext Framework. In general, this means that most +TODAY Framework 5.0 introduced basic support for executing tests in parallel within a +single JVM when using the Infra TestContext Framework. In general, this means that most test classes or test methods can be run in parallel without any changes to test code or configuration. @@ -11,13 +11,13 @@ testing framework, build tool, or IDE. Keep in mind that the introduction of concurrency into your test suite can result in unexpected side effects, strange runtime behavior, and tests that fail intermittently or -seemingly randomly. The Spring Team therefore provides the following general guidelines +seemingly randomly. The Infra Team therefore provides the following general guidelines for when not to run tests in parallel. Do not run tests in parallel if the tests: -* Use Spring Framework's `@DirtiesContext` support. -* Use Spring Boot's `@MockBean` or `@SpyBean` support. +* Use TODAY Framework's `@DirtiesContext` support. +* Use Infra App's `@MockBean` or `@SpyBean` support. * Use JUnit 4's `@FixMethodOrder` support or any testing framework feature that is designed to ensure that test methods run in a particular order. Note, however, that this does not apply if entire test classes are run in parallel. @@ -38,10 +38,10 @@ of the cache. See the discussion on xref:testing/testcontext-framework/ctx-manag for details. ==== -WARNING: Parallel test execution in the Spring TestContext Framework is only possible if +WARNING: Parallel test execution in the Infra TestContext Framework is only possible if the underlying `TestContext` implementation provides a copy constructor, as explained in the javadoc for {today-framework-api}/test/context/TestContext.html[`TestContext`]. The -`DefaultTestContext` used in Spring provides such a constructor. However, if you use a +`DefaultTestContext` used in Infra provides such a constructor. However, if you use a third-party library that provides a custom `TestContext` implementation, you need to verify that it is suitable for parallel test execution. diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc index b3ec751ffb..f471494276 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/support-classes.adoc @@ -1,24 +1,24 @@ [[testcontext-support-classes]] = TestContext Framework Support Classes -This section describes the various classes that support the Spring TestContext Framework. +This section describes the various classes that support the Infra TestContext Framework. [[testcontext-junit4-runner]] -== Spring JUnit 4 Runner +== Infra JUnit 4 Runner -The Spring TestContext Framework offers full integration with JUnit 4 through a custom +The Infra TestContext Framework offers full integration with JUnit 4 through a custom runner (supported on JUnit 4.12 or higher). By annotating test classes with -`@RunWith(SpringJUnit4ClassRunner.class)` or the shorter `@RunWith(SpringRunner.class)` +`@RunWith(InfraJUnit4ClassRunner.class)` or the shorter `@RunWith(InfraRunner.class)` variant, developers can implement standard JUnit 4-based unit and integration tests and simultaneously reap the benefits of the TestContext framework, such as support for loading application contexts, dependency injection of test instances, transactional test -method execution, and so on. If you want to use the Spring TestContext Framework with an +method execution, and so on. If you want to use the Infra TestContext Framework with an alternative runner (such as JUnit 4's `Parameterized` runner) or third-party runners (such as the `MockitoJUnitRunner`), you can, optionally, use -xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Spring's support for JUnit rules] instead. +xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Infra support for JUnit rules] instead. The following code listing shows the minimal requirements for configuring a test class to -run with the custom Spring `Runner`: +run with the custom Infra `Runner`: [tabs] ====== @@ -26,7 +26,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@RunWith(SpringRunner.class) +@RunWith(InfraRunner.class) @TestExecutionListeners({}) public class SimpleTest { @@ -43,25 +43,25 @@ disable the default listeners, which otherwise would require an `ApplicationCont be configured through `@ContextConfiguration`. [[testcontext-junit4-rules]] -== Spring JUnit 4 Rules +== Infra JUnit 4 Rules The `cn.taketoday.test.context.junit4.rules` package provides the following JUnit 4 rules (supported on JUnit 4.12 or higher): -* `SpringClassRule` -* `SpringMethodRule` +* `InfraClassRule` +* `InfraMethodRule` -`SpringClassRule` is a JUnit `TestRule` that supports class-level features of the Spring -TestContext Framework, whereas `SpringMethodRule` is a JUnit `MethodRule` that supports -instance-level and method-level features of the Spring TestContext Framework. +`InfraClassRule` is a JUnit `TestRule` that supports class-level features of the Infra +TestContext Framework, whereas `InfraMethodRule` is a JUnit `MethodRule` that supports +instance-level and method-level features of the Infra TestContext Framework. -In contrast to the `SpringRunner`, Spring's rule-based JUnit support has the advantage of +In contrast to the `InfraRunner`, Infra rule-based JUnit support has the advantage of being independent of any `org.junit.runner.Runner` implementation and can, therefore, be combined with existing alternative runners (such as JUnit 4's `Parameterized`) or third-party runners (such as the `MockitoJUnitRunner`). To support the full functionality of the TestContext framework, you must combine a -`SpringClassRule` with a `SpringMethodRule`. The following example shows the proper way +`InfraClassRule` with a `InfraMethodRule`. The following example shows the proper way to declare these rules in an integration test: [tabs] @@ -70,15 +70,15 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -// Optionally specify a non-Spring Runner via @RunWith(...) +// Optionally specify a non-Infra Runner via @RunWith(...) @ContextConfiguration public class IntegrationTest { @ClassRule - public static final SpringClassRule springClassRule = new SpringClassRule(); + public static final InfraClassRule springClassRule = new InfraClassRule(); @Rule - public final SpringMethodRule springMethodRule = new SpringMethodRule(); + public final InfraMethodRule springMethodRule = new InfraMethodRule(); @Test public void testMethod() { @@ -94,48 +94,48 @@ public class IntegrationTest { The `cn.taketoday.test.context.junit4` package provides the following support classes for JUnit 4-based test cases (supported on JUnit 4.12 or higher): -* `AbstractJUnit4SpringContextTests` -* `AbstractTransactionalJUnit4SpringContextTests` +* `AbstractJUnit4InfraContextTests` +* `AbstractTransactionalJUnit4InfraContextTests` -`AbstractJUnit4SpringContextTests` is an abstract base test class that integrates the -Spring TestContext Framework with explicit `ApplicationContext` testing support in a -JUnit 4 environment. When you extend `AbstractJUnit4SpringContextTests`, you can access a +`AbstractJUnit4InfraContextTests` is an abstract base test class that integrates the +Infra TestContext Framework with explicit `ApplicationContext` testing support in a +JUnit 4 environment. When you extend `AbstractJUnit4InfraContextTests`, you can access a `protected` `applicationContext` instance variable that you can use to perform explicit bean lookups or to test the state of the context as a whole. -`AbstractTransactionalJUnit4SpringContextTests` is an abstract transactional extension of -`AbstractJUnit4SpringContextTests` that adds some convenience functionality for JDBC +`AbstractTransactionalJUnit4InfraContextTests` is an abstract transactional extension of +`AbstractJUnit4InfraContextTests` that adds some convenience functionality for JDBC access. This class expects a `javax.sql.DataSource` bean and a `PlatformTransactionManager` bean to be defined in the `ApplicationContext`. When you -extend `AbstractTransactionalJUnit4SpringContextTests`, you can access a `protected` +extend `AbstractTransactionalJUnit4InfraContextTests`, you can access a `protected` `jdbcTemplate` instance variable that you can use to run SQL statements to query the database. You can use such queries to confirm database state both before and after -running database-related application code, and Spring ensures that such queries run in +running database-related application code, and Infra ensures that such queries run in the scope of the same transaction as the application code. When used in conjunction with an ORM tool, be sure to avoid xref:testing/testcontext-framework/tx.adoc#testcontext-tx-false-positives[false positives]. As mentioned in xref:testing/support-jdbc.adoc[JDBC Testing Support], -`AbstractTransactionalJUnit4SpringContextTests` also provides convenience methods that +`AbstractTransactionalJUnit4InfraContextTests` also provides convenience methods that delegate to methods in `JdbcTestUtils` by using the aforementioned `jdbcTemplate`. Furthermore, `AbstractTransactionalJUnit4SpringContextTests` provides an `executeSqlScript(..)` method for running SQL scripts against the configured `DataSource`. TIP: These classes are a convenience for extension. If you do not want your test classes -to be tied to a Spring-specific class hierarchy, you can configure your own custom test -classes by using `@RunWith(SpringRunner.class)` or xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Spring's JUnit rules] +to be tied to a Infra-specific class hierarchy, you can configure your own custom test +classes by using `@RunWith(SpringRunner.class)` or xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit4-rules[Infra JUnit rules] . [[testcontext-junit-jupiter-extension]] == SpringExtension for JUnit Jupiter -The Spring TestContext Framework offers full integration with the JUnit Jupiter testing +The Infra TestContext Framework offers full integration with the JUnit Jupiter testing framework, introduced in JUnit 5. By annotating test classes with `@ExtendWith(SpringExtension.class)`, you can implement standard JUnit Jupiter-based unit and integration tests and simultaneously reap the benefits of the TestContext framework, such as support for loading application contexts, dependency injection of test instances, transactional test method execution, and so on. -Furthermore, thanks to the rich extension API in JUnit Jupiter, Spring provides the -following features above and beyond the feature set that Spring supports for JUnit 4 and +Furthermore, thanks to the rich extension API in JUnit Jupiter, Infra provides the +following features above and beyond the feature set that Infra supports for JUnit 4 and TestNG: * Dependency injection for test constructors, test methods, and test lifecycle callback @@ -143,8 +143,8 @@ TestNG: * Powerful support for link:https://junit.org/junit5/docs/current/user-guide/#extensions-conditions[conditional test execution] based on SpEL expressions, environment variables, system properties, and so on. See the documentation for `@EnabledIf` and `@DisabledIf` in - xref:testing/annotations/integration-junit-jupiter.adoc[Spring JUnit Jupiter Testing Annotations] for further details and examples. -* Custom composed annotations that combine annotations from Spring and JUnit Jupiter. See + xref:testing/annotations/integration-junit-jupiter.adoc[Infra JUnit Jupiter Testing Annotations] for further details and examples. +* Custom composed annotations that combine annotations from Infra and JUnit Jupiter. See the `@TransactionalDevTestConfig` and `@TransactionalIntegrationTest` examples in xref:testing/annotations/integration-meta.adoc[Meta-Annotation Support for Testing] for further details. @@ -157,9 +157,9 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -// Instructs JUnit Jupiter to extend the test with Spring support. +// Instructs JUnit Jupiter to extend the test with Infra support. @ExtendWith(SpringExtension.class) -// Instructs Spring to load an ApplicationContext from TestConfig.class +// Instructs Infra to load an ApplicationContext from TestConfig.class @ContextConfiguration(classes = TestConfig.class) class SimpleTests { @@ -171,11 +171,11 @@ class SimpleTests { ---- ====== -Since you can also use annotations in JUnit 5 as meta-annotations, Spring provides the -`@SpringJUnitConfig` and `@SpringJUnitWebConfig` composed annotations to simplify the +Since you can also use annotations in JUnit 5 as meta-annotations, Infra provides the +`@JUnitConfig` and `@JUnitWebConfig` composed annotations to simplify the configuration of the test `ApplicationContext` and JUnit Jupiter. -The following example uses `@SpringJUnitConfig` to reduce the amount of configuration +The following example uses `@JUnitConfig` to reduce the amount of configuration used in the previous example: [tabs] @@ -184,9 +184,9 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -// Instructs Spring to register the SpringExtension with JUnit +// Instructs Infra to register the SpringExtension with JUnit // Jupiter and load an ApplicationContext from TestConfig.class -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) class SimpleTests { @Test @@ -198,7 +198,7 @@ class SimpleTests { ====== -Similarly, the following example uses `@SpringJUnitWebConfig` to create a +Similarly, the following example uses `@JUnitWebConfig` to create a `WebApplicationContext` for use with JUnit Jupiter: [tabs] @@ -207,9 +207,9 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -// Instructs Spring to register the SpringExtension with JUnit +// Instructs Infra to register the SpringExtension with JUnit // Jupiter and load a WebApplicationContext from TestWebConfig.class -@SpringJUnitWebConfig(TestWebConfig.class) +@JUnitWebConfig(TestWebConfig.class) class SimpleWebTests { @Test @@ -221,20 +221,20 @@ class SimpleWebTests { ====== -See the documentation for `@SpringJUnitConfig` and `@SpringJUnitWebConfig` in -xref:testing/annotations/integration-junit-jupiter.adoc[Spring JUnit Jupiter Testing Annotations] for further details. +See the documentation for `@JUnitConfig` and `@JUnitWebConfig` in +xref:testing/annotations/integration-junit-jupiter.adoc[Infra JUnit Jupiter Testing Annotations] for further details. [[testcontext-junit-jupiter-di]] === Dependency Injection with the `SpringExtension` The `SpringExtension` implements the link:https://junit.org/junit5/docs/current/user-guide/#extensions-parameter-resolution[`ParameterResolver`] -extension API from JUnit Jupiter, which lets Spring provide dependency injection for test +extension API from JUnit Jupiter, which lets Infra provide dependency injection for test constructors, test methods, and test lifecycle callback methods. Specifically, the `SpringExtension` can inject dependencies from the test's `ApplicationContext` into test constructors and methods that are annotated with -Spring's `@BeforeTransaction` and `@AfterTransaction` or JUnit's `@BeforeAll`, +Infra `@BeforeTransaction` and `@AfterTransaction` or JUnit's `@BeforeAll`, `@AfterAll`, `@BeforeEach`, `@AfterEach`, `@Test`, `@RepeatedTest`, `@ParameterizedTest`, and others. @@ -244,10 +244,10 @@ and others. If a specific parameter in a constructor for a JUnit Jupiter test class is of type `ApplicationContext` (or a sub-type thereof) or is annotated or meta-annotated with -`@Autowired`, `@Qualifier`, or `@Value`, Spring injects the value for that specific +`@Autowired`, `@Qualifier`, or `@Value`, Infra injects the value for that specific parameter with the corresponding bean or value from the test's `ApplicationContext`. -Spring can also be configured to autowire all arguments for a test class constructor if +Infra can also be configured to autowire all arguments for a test class constructor if the constructor is considered to be _autowirable_. A constructor is considered to be autowirable if one of the following conditions is met (in order of precedence). @@ -259,7 +259,7 @@ autowirable if one of the following conditions is met (in order of precedence). See xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-testconstructor[`@TestConstructor`] for details on the use of `@TestConstructor` and how to change the global _test constructor autowire mode_. -WARNING: If the constructor for a test class is considered to be _autowirable_, Spring +WARNING: If the constructor for a test class is considered to be _autowirable_, Infra assumes the responsibility for resolving arguments for all parameters in the constructor. Consequently, no other `ParameterResolver` registered with JUnit Jupiter can resolve parameters for such a constructor. @@ -278,12 +278,12 @@ once in such scenarios, dependency injection will not occur again, and subsequen will interact with beans from the closed `ApplicationContext` which may result in errors. To use `@DirtiesContext` with "before test method" or "after test method" modes in -conjunction with `@TestInstance(PER_CLASS)`, one must configure dependencies from Spring +conjunction with `@TestInstance(PER_CLASS)`, one must configure dependencies from Infra to be supplied via field or setter injection so that they can be re-injected between test method invocations. ==== -In the following example, Spring injects the `OrderService` bean from the +In the following example, Infra injects the `OrderService` bean from the `ApplicationContext` loaded from `TestConfig.class` into the `OrderServiceIntegrationTests` constructor. @@ -293,7 +293,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) class OrderServiceIntegrationTests { private final OrderService orderService; @@ -321,7 +321,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) class OrderServiceIntegrationTests { private final OrderService orderService; @@ -340,10 +340,10 @@ class OrderServiceIntegrationTests { If a parameter in a JUnit Jupiter test method or test lifecycle callback method is of type `ApplicationContext` (or a sub-type thereof) or is annotated or meta-annotated with -`@Autowired`, `@Qualifier`, or `@Value`, Spring injects the value for that specific +`@Autowired`, `@Qualifier`, or `@Value`, Infra injects the value for that specific parameter with the corresponding bean from the test's `ApplicationContext`. -In the following example, Spring injects the `OrderService` from the `ApplicationContext` +In the following example, Infra injects the `OrderService` from the `ApplicationContext` loaded from `TestConfig.class` into the `deleteOrder()` test method: [tabs] @@ -352,7 +352,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) class OrderServiceIntegrationTests { @Test @@ -377,7 +377,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) class OrderServiceIntegrationTests { @RepeatedTest(10) @@ -399,11 +399,11 @@ to the `RepetitionInfo`. === `@Nested` test class configuration The _Spring TestContext Framework_ has supported the use of test-related annotations on -`@Nested` test classes in JUnit Jupiter since Spring Framework 5.0; however, until Spring +`@Nested` test classes in JUnit Jupiter since TODAY Framework 5.0; however, until Spring Framework 5.3 class-level test configuration annotations were not _inherited_ from enclosing classes like they are from superclasses. -Spring Framework 5.3 introduced first-class support for inheriting test class +TODAY Framework 5.3 introduced first-class support for inheriting test class configuration from enclosing classes, and such configuration will be inherited by default. To change from the default `INHERIT` mode to `OVERRIDE` mode, you may annotate an individual `@Nested` test class with @@ -414,7 +414,7 @@ with `@NestedTestConfiguration`, and that will apply to all of its nested test c recursively. In order to allow development teams to change the default to `OVERRIDE` – for example, -for compatibility with Spring Framework 5.0 through 5.2 – the default mode can be changed +for compatibility with TODAY Framework 5.0 through 5.2 – the default mode can be changed globally via a JVM system property or a `spring.properties` file in the root of the classpath. See the xref:testing/annotations/integration-junit-jupiter.adoc#integration-testing-annotations-nestedtestconfiguration["Changing the default enclosing configuration inheritance mode"] note for details. @@ -434,7 +434,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) class GreetingServiceTests { @Nested diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tel-config.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tel-config.adoc index af031454e6..d0e5137525 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tel-config.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tel-config.adoc @@ -1,7 +1,7 @@ [[testcontext-tel-config]] = `TestExecutionListener` Configuration -Spring provides the following `TestExecutionListener` implementations that are registered +Infra provides the following `TestExecutionListener` implementations that are registered by default, exactly in the following order: * `ServletTestExecutionListener`: Configures Servlet API mocks for a @@ -67,11 +67,11 @@ Registering `TestExecutionListener` implementations by using `@TestExecutionList suitable for custom listeners that are used in limited testing scenarios. However, it can become cumbersome if a custom listener needs to be used across an entire test suite. This issue is addressed through support for automatic discovery of default -`TestExecutionListener` implementations through the `SpringFactoriesLoader` mechanism. +`TestExecutionListener` implementations through the `InfraFactoriesLoader` mechanism. -For example, the `spring-test` module declares all core default `TestExecutionListener` +For example, the `today-test` module declares all core default `TestExecutionListener` implementations under the `cn.taketoday.test.context.TestExecutionListener` key in -its {today-framework-code}/spring-test/src/main/resources/META-INF/spring.factories[`META-INF/spring.factories` +its {today-framework-code}/today-test/src/main/resources/META-INF/spring.factories[`META-INF/spring.factories` properties file]. Third-party frameworks and developers can contribute their own `TestExecutionListener` implementations to the list of default listeners in the same manner through their own `spring.factories` files. @@ -81,10 +81,10 @@ manner through their own `spring.factories` files. When the TestContext framework discovers default `TestExecutionListener` implementations through the xref:testing/testcontext-framework/tel-config.adoc#testcontext-tel-config-automatic-discovery[aforementioned] -`SpringFactoriesLoader` mechanism, the instantiated listeners are sorted by using -Spring's `AnnotationAwareOrderComparator`, which honors Spring's `Ordered` interface and +`InfraFactoriesLoader` mechanism, the instantiated listeners are sorted by using +Infra `AnnotationAwareOrderComparator`, which honors Infra `Ordered` interface and `@Order` annotation for ordering. `AbstractTestExecutionListener` and all default -`TestExecutionListener` implementations provided by Spring implement `Ordered` with +`TestExecutionListener` implementations provided by Infra implement `Ordered` with appropriate values. Third-party frameworks and developers should therefore make sure that their default `TestExecutionListener` implementations are registered in the proper order by implementing `Ordered` or declaring `@Order`. See the javadoc for the `getOrder()` @@ -125,9 +125,9 @@ class MyTest { The challenge with this approach is that it requires that the developer know exactly which listeners are registered by default. Moreover, the set of default listeners can change from release to release -- for example, `SqlScriptsTestExecutionListener` was -introduced in Spring Framework 4.1, and `DirtiesContextBeforeModesTestExecutionListener` -was introduced in Spring Framework 4.2. Furthermore, third-party frameworks like Spring -Boot and Spring Security register their own default `TestExecutionListener` +introduced in TODAY Framework 4.1, and `DirtiesContextBeforeModesTestExecutionListener` +was introduced in TODAY Framework 4.2. Furthermore, third-party frameworks like Infra +Boot and Infra Security register their own default `TestExecutionListener` implementations by using the aforementioned xref:testing/testcontext-framework/tel-config.adoc#testcontext-tel-config-automatic-discovery[automatic discovery mechanism] . diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc index 48136b35d9..43af83e6cd 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/test-execution-events.adoc @@ -1,7 +1,7 @@ [[testcontext-test-execution-events]] = Test Execution Events -The `EventPublishingTestExecutionListener` introduced in Spring Framework 5.2 offers an +The `EventPublishingTestExecutionListener` introduced in TODAY Framework 5.2 offers an alternative approach to implementing a custom `TestExecutionListener`. Components in the test's `ApplicationContext` can listen to the following events published by the `EventPublishingTestExecutionListener`, each of which corresponds to a method in the @@ -18,7 +18,7 @@ test's `ApplicationContext` can listen to the following events published by the These events may be consumed for various reasons, such as resetting mock beans or tracing test execution. One advantage of consuming test execution events rather than implementing a custom `TestExecutionListener` is that test execution events may be consumed by any -Spring bean registered in the test `ApplicationContext`, and such beans may benefit +Infra bean registered in the test `ApplicationContext`, and such beans may benefit directly from dependency injection and other features of the `ApplicationContext`. In contrast, a `TestExecutionListener` is not a bean in the `ApplicationContext`. @@ -48,12 +48,12 @@ context cache after the last test method in a given test class, the `AfterTestCl will not be published for that test class. ==== -In order to listen to test execution events, a Spring bean may choose to implement the +In order to listen to test execution events, a Infra bean may choose to implement the `cn.taketoday.context.ApplicationListener` interface. Alternatively, listener methods can be annotated with `@EventListener` and configured to listen to one of the particular event types listed above (see xref:core/beans/context-introduction.adoc#context-functionality-events-annotation[Annotation-based Event Listeners]). -Due to the popularity of this approach, Spring provides the following dedicated +Due to the popularity of this approach, Infra provides the following dedicated `@EventListener` annotations to simplify registration of test execution event listeners. These annotations reside in the `cn.taketoday.test.context.event.annotation` package. @@ -81,7 +81,7 @@ asynchronous exception handling, consult the class-level javadoc for `@EventList == Asynchronous Listeners If you want a particular test execution event listener to process events asynchronously, -you can use Spring's xref:integration/scheduling.adoc#scheduling-annotation-support-async[regular `@Async` support] +you can use Infra xref:integration/scheduling.adoc#scheduling-annotation-support-async[regular `@Async` support] . For further details, consult the class-level javadoc for `@EventListener`. diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc index 6a62f73e50..e20b89d1b6 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/tx.adoc @@ -6,7 +6,7 @@ In the TestContext framework, transactions are managed by the explicitly declare `@TestExecutionListeners` on your test class. To enable support for transactions, however, you must configure a `PlatformTransactionManager` bean in the `ApplicationContext` that is loaded with `@ContextConfiguration` semantics (further -details are provided later). In addition, you must declare Spring's `@Transactional` +details are provided later). In addition, you must declare Infra `@Transactional` annotation either at the class or the method level for your tests. [[testcontext-tx-test-managed-transactions]] @@ -14,12 +14,12 @@ annotation either at the class or the method level for your tests. Test-managed transactions are transactions that are managed declaratively by using the `TransactionalTestExecutionListener` or programmatically by using `TestTransaction` -(described later). You should not confuse such transactions with Spring-managed -transactions (those managed directly by Spring within the `ApplicationContext` loaded for +(described later). You should not confuse such transactions with Infra-managed +transactions (those managed directly by Infra within the `ApplicationContext` loaded for tests) or application-managed transactions (those managed programmatically within -application code that is invoked by tests). Spring-managed and application-managed +application code that is invoked by tests). Infra-managed and application-managed transactions typically participate in test-managed transactions. However, you should use -caution if Spring-managed or application-managed transactions are configured with any +caution if Infra-managed or application-managed transactions are configured with any propagation type other than `REQUIRED` or `SUPPORTS` (see the discussion on xref:data-access/transaction/declarative/tx-propagation.adoc[transaction propagation] for details). @@ -27,16 +27,16 @@ xref:data-access/transaction/declarative/tx-propagation.adoc[transaction propaga [WARNING] ==== Caution must be taken when using any form of preemptive timeouts from a testing framework -in conjunction with Spring's test-managed transactions. +in conjunction with Infra test-managed transactions. -Specifically, Spring’s testing support binds transaction state to the current thread (via +Specifically, Infra’s testing support binds transaction state to the current thread (via a `java.lang.ThreadLocal` variable) _before_ the current test method is invoked. If a testing framework invokes the current test method in a new thread in order to support a preemptive timeout, any actions performed within the current test method will _not_ be invoked within the test-managed transaction. Consequently, the result of any such actions will not be rolled back with the test-managed transaction. On the contrary, such actions will be committed to the persistent store -- for example, a relational database -- even -though the test-managed transaction is properly rolled back by Spring. +though the test-managed transaction is properly rolled back by Infra. Situations in which this can occur include but are not limited to the following. @@ -94,9 +94,9 @@ your test class and then use that with a `TransactionTemplate` for programmatic transaction management. ==== -Note that xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4SpringContextTests`] +Note that xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-junit4[`AbstractTransactionalJUnit4InfraContextTests`] and -xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGSpringContextTests`] +xref:testing/testcontext-framework/support-classes.adoc#testcontext-support-classes-testng[`AbstractTransactionalTestNGInfraContextTests`] are preconfigured for transactional support at the class level. The following example demonstrates a common scenario for writing an integration test for @@ -108,7 +108,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig(TestConfig.class) +@JUnitConfig(TestConfig.class) @Transactional class HibernateUserRepositoryTests { @@ -183,7 +183,7 @@ Java:: ---- @ContextConfiguration(classes = TestConfig.class) public class ProgrammaticTransactionManagementTests extends - AbstractTransactionalJUnit4SpringContextTests { + AbstractTransactionalJUnit4InfraContextTests { @Test public void transactionalTest() { @@ -230,10 +230,10 @@ Generally speaking, `@BeforeTransaction` and `@AfterTransaction` methods must no any arguments. However, as of TODAY Framework 6.1, for tests using the -xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-extension[`SpringExtension`] +xref:testing/testcontext-framework/support-classes.adoc#testcontext-junit-jupiter-extension[`InfraExtension`] with JUnit Jupiter, `@BeforeTransaction` and `@AfterTransaction` methods may optionally accept arguments which will be resolved by any registered JUnit `ParameterResolver` -extension such as the `SpringExtension`. This means that JUnit-specific arguments like +extension such as the `InfraExtension`. This means that JUnit-specific arguments like `TestInfo` or beans from the test's `ApplicationContext` may be provided to `@BeforeTransaction` and `@AfterTransaction` methods, as demonstrated in the following example. @@ -267,7 +267,7 @@ run for transactional test methods. == Configuring a Transaction Manager `TransactionalTestExecutionListener` expects a `PlatformTransactionManager` bean to be -defined in the Spring `ApplicationContext` for the test. If there are multiple instances +defined in the Infra `ApplicationContext` for the test. If there are multiple instances of `PlatformTransactionManager` within the test's `ApplicationContext`, you can declare a qualifier by using `@Transactional("myTxMgr")` or `@Transactional(transactionManager = "myTxMgr")`, or `TransactionManagementConfigurer` can be implemented by an @@ -294,7 +294,7 @@ Java:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitConfig +@JUnitConfig @Transactional(transactionManager = "txMgr") @Commit class FictitiousTransactionalTest { @@ -466,8 +466,8 @@ Java:: ====== See -{today-framework-code}/spring-test/src/test/java/cn/taketoday/test/context/junit/jupiter/orm/JpaEntityListenerTests.java[JpaEntityListenerTests] -in the Spring Framework test suite for working examples using all JPA lifecycle callbacks. +{today-framework-code}/today-test/src/test/java/cn/taketoday/test/context/junit/jupiter/orm/JpaEntityListenerTests.java[JpaEntityListenerTests] +in the TODAY Framework test suite for working examples using all JPA lifecycle callbacks. ===== diff --git a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/web-scoped-beans.adoc b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/web-scoped-beans.adoc index 578143f7de..e60daf68ff 100644 --- a/infra-docs/modules/ROOT/pages/testing/testcontext-framework/web-scoped-beans.adoc +++ b/infra-docs/modules/ROOT/pages/testing/testcontext-framework/web-scoped-beans.adoc @@ -1,7 +1,7 @@ [[testcontext-web-scoped-beans]] = Testing Request- and Session-scoped Beans -Spring has supported xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other[Request- and session-scoped beans] +Infra has supported xref:core/beans/factory-scopes.adoc#beans-factory-scopes-other[Request- and session-scoped beans] since the early years, and you can test your request-scoped and session-scoped beans by following these steps: @@ -53,7 +53,7 @@ Request-scoped bean test:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig +@JUnitWebConfig class RequestScopedBeanTests { @Autowired UserService userService; @@ -110,7 +110,7 @@ Session-scoped bean test:: + [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@SpringJUnitWebConfig +@JUnitWebConfig class SessionScopedBeanTests { @Autowired UserService userService; diff --git a/infra-docs/modules/ROOT/pages/testing/unit.adoc b/infra-docs/modules/ROOT/pages/testing/unit.adoc index aaf302908b..103fa147bc 100644 --- a/infra-docs/modules/ROOT/pages/testing/unit.adoc +++ b/infra-docs/modules/ROOT/pages/testing/unit.adoc @@ -4,9 +4,9 @@ Dependency injection should make your code less dependent on the container than it would be with traditional J2EE / Java EE development. The POJOs that make up your application should be testable in JUnit or TestNG tests, with objects instantiated by using the `new` -operator, without Spring or any other container. You can use xref:testing/unit.adoc#mock-objects[mock objects] +operator, without Infra or any other container. You can use xref:testing/unit.adoc#mock-objects[mock objects] (in conjunction with other valuable testing techniques) to test your code in isolation. -If you follow the architecture recommendations for Spring, the resulting clean layering +If you follow the architecture recommendations for Infra, the resulting clean layering and componentization of your codebase facilitate easier unit testing. For example, you can test service layer objects by stubbing or mocking DAO or repository interfaces, without needing to access persistent data while running unit tests. @@ -23,12 +23,12 @@ are described in this chapter. [[mock-objects]] == Mock Objects -Spring includes a number of packages dedicated to mocking: +Infra includes a number of packages dedicated to mocking: * xref:testing/unit.adoc#mock-objects-env[Environment] * xref:testing/unit.adoc#mock-objects-jndi[JNDI] * xref:testing/unit.adoc#mock-objects-servlet[Servlet API] -* xref:testing/unit.adoc#mock-objects-web-reactive[Spring Web Reactive] +* xref:testing/unit.adoc#mock-objects-web-reactive[Infra Web Reactive] [[mock-objects-env]] @@ -61,7 +61,7 @@ parties such as https://github.com/h-thurow/Simple-JNDI[Simple-JNDI]. The `cn.taketoday.mock.web` package contains a comprehensive set of Servlet API mock objects that are useful for testing web contexts, controllers, and filters. These -mock objects are targeted at usage with Spring's Web MVC framework and are generally more +mock objects are targeted at usage with Infra Web MVC framework and are generally more convenient to use than dynamic mock objects (such as https://easymock.org/[EasyMock]) or alternative Servlet API mock objects (such as http://www.mockobjects.com[MockObjects]). @@ -73,7 +73,7 @@ integration testing framework for Web MVC. See xref:testing/spring-mvc-test-fram [[mock-objects-web-reactive]] -=== Spring Web Reactive +=== Infra Web Reactive The `cn.taketoday.mock.http.server.reactive` package contains mock implementations of `ServerHttpRequest` and `ServerHttpResponse` for use in WebFlux applications. The @@ -99,7 +99,7 @@ end-to-end tests with a running server. [[unit-testing-support-classes]] == Unit Testing Support Classes -Spring includes a number of classes that can help with unit testing. They fall into two +Infra includes a number of classes that can help with unit testing. They fall into two categories: * xref:testing/unit.adoc#unit-testing-utilities[General Testing Utilities] @@ -114,10 +114,10 @@ for use in unit and integration testing. {today-framework-api}/test/util/AopTestUtils.html[`AopTestUtils`] is a collection of AOP-related utility methods. You can use these methods to obtain a reference to the -underlying target object hidden behind one or more Spring proxies. For example, if you +underlying target object hidden behind one or more Infra proxies. For example, if you have configured a bean as a dynamic mock by using a library such as EasyMock or Mockito, -and the mock is wrapped in a Spring proxy, you may need direct access to the underlying -mock to configure expectations on it and perform verifications. For Spring's core AOP +and the mock is wrapped in a Infra proxy, you may need direct access to the underlying +mock to configure expectations on it and perform verifications. For Infra core AOP utilities, see {today-framework-api}/aop/support/AopUtils.html[`AopUtils`] and {today-framework-api}/aop/framework/AopProxyUtils.html[`AopProxyUtils`]. @@ -129,7 +129,7 @@ callback method when testing application code for use cases such as the followin * ORM frameworks (such as JPA and Hibernate) that condone `private` or `protected` field access as opposed to `public` setter methods for properties in a domain entity. -* Spring's support for annotations (such as `@Autowired`, `@Inject`, and `@Resource`), +* Infra support for annotations (such as `@Autowired`, `@Inject`, and `@Resource`), that provide dependency injection for `private` or `protected` fields, setter methods, and configuration methods. * Use of annotations such as `@PostConstruct` and `@PreDestroy` for lifecycle callback @@ -161,7 +161,7 @@ that deal with Web MVC `ModelAndView` objects. .Unit testing Web MVC Controllers TIP: To unit test your Web MVC `Controller` classes as POJOs, use `ModelAndViewAssert` -combined with `MockHttpServletRequest`, `MockHttpSession`, and so on from Spring's +combined with `MockHttpServletRequest`, `MockHttpSession`, and so on from Infra xref:testing/unit.adoc#mock-objects-servlet[Servlet API mocks]. For thorough integration testing of your Web MVC and REST `Controller` classes in conjunction with your `WebApplicationContext` configuration for Web MVC, use the diff --git a/infra-docs/modules/ROOT/pages/testing/webtestclient.adoc b/infra-docs/modules/ROOT/pages/testing/webtestclient.adoc index 1cd3b02319..dda9b24390 100644 --- a/infra-docs/modules/ROOT/pages/testing/webtestclient.adoc +++ b/infra-docs/modules/ROOT/pages/testing/webtestclient.adoc @@ -4,7 +4,7 @@ `WebTestClient` is an HTTP client designed for testing server applications. It wraps WebClient and uses it to perform requests but exposes a testing facade for verifying responses. `WebTestClient` can be used to -perform end-to-end HTTP tests. It can also be used to test Web MVC and Spring WebFlux +perform end-to-end HTTP tests. It can also be used to test Web MVC and Infra WebFlux applications without a running server via mock server request and response objects. @@ -60,18 +60,18 @@ WebTestClient client = [[webtestclient-context-config]] === Bind to `ApplicationContext` -This setup allows you to load Spring configuration with Web MVC or Spring WebFlux +This setup allows you to load Infra configuration with Web MVC or Infra WebFlux infrastructure and controller declarations and use it to handle requests via mock request and response objects, without a running server. -For Web MVC, use the following where the Spring `ApplicationContext` is passed to +For Web MVC, use the following where the Infra `ApplicationContext` is passed to {today-framework-api}/test/web/servlet/setup/MockMvcBuilders.html#webAppContextSetup-cn.taketoday.web.context.WebApplicationContext-[MockMvcBuilders.webAppContextSetup] to create a xref:testing/spring-mvc-test-framework.adoc[MockMvc] instance to handle requests: [source,java,indent=0,subs="verbatim,quotes",role="primary"] ---- -@ExtendWith(SpringExtension.class) +@ExtendWith(InfraExtension.class) @WebAppConfiguration("classpath:META-INF/web-resources") // <1> @ContextHierarchy({ @ContextConfiguration(classes = RootConfig.class), diff --git a/infra-docs/modules/ROOT/pages/web/integration.adoc b/infra-docs/modules/ROOT/pages/web/integration.adoc index c9038a8ea2..f60dc30ef8 100644 --- a/infra-docs/modules/ROOT/pages/web/integration.adoc +++ b/infra-docs/modules/ROOT/pages/web/integration.adoc @@ -1,14 +1,14 @@ [[web-integration]] = Other Web Frameworks -This chapter details Spring's integration with third-party web frameworks. +This chapter details Infra integration with third-party web frameworks. One of the core value propositions of the TODAY Framework is that of enabling -_choice_. In a general sense, Spring does not force you to use or buy into any +_choice_. In a general sense, Infra does not force you to use or buy into any particular architecture, technology, or methodology (although it certainly recommends some over others). This freedom to pick and choose the architecture, technology, or methodology that is most relevant to a developer and their development team is -arguably most evident in the web area, where Spring provides its own web frameworks +arguably most evident in the web area, where Infra provides its own web frameworks (xref:web/webmvc.adoc#mvc[Web MVC]) while, at the same time, supporting integration with a number of popular third-party web frameworks. @@ -19,26 +19,26 @@ supporting integration with a number of popular third-party web frameworks. == Common Configuration Before diving into the integration specifics of each supported web framework, let us -first take a look at common Spring configuration that is not specific to any one web -framework. (This section is equally applicable to Spring's own web framework variants.) +first take a look at common Infra configuration that is not specific to any one web +framework. (This section is equally applicable to Infra own web framework variants.) -One of the concepts (for want of a better word) espoused by Spring's lightweight +One of the concepts (for want of a better word) espoused by Infra lightweight application model is that of a layered architecture. Remember that in a "classic" layered architecture, the web layer is but one of many layers. It serves as one of the entry points into a server-side application, and it delegates to service objects (facades) that are defined in a service layer to satisfy business-specific (and -presentation-technology agnostic) use cases. In Spring, these service objects, any other +presentation-technology agnostic) use cases. In Infra, these service objects, any other business-specific objects, data-access objects, and others exist in a distinct "business context", which contains no web or presentation layer objects (presentation objects, such as Web MVC controllers, are typically configured in a distinct "presentation -context"). This section details how you can configure a Spring container (a +context"). This section details how you can configure a Infra container (a `WebApplicationContext`) that contains all of the 'business beans' in your application. Moving on to specifics, all you need to do is declare a {today-framework-api}/web/context/ContextLoaderListener.html[`ContextLoaderListener`] in the standard Jakarta EE servlet `web.xml` file of your web application and add a `contextConfigLocation` `` section (in the same file) that defines which -set of Spring XML configuration files to load. +set of Infra XML configuration files to load. Consider the following `` configuration: @@ -61,7 +61,7 @@ Further consider the following `` configuration: If you do not specify the `contextConfigLocation` context parameter, the `ContextLoaderListener` looks for a file called `/WEB-INF/applicationContext.xml` to -load. Once the context files are loaded, Spring creates a +load. Once the context files are loaded, Infra creates a {today-framework-api}/web/context/WebApplicationContext.html[`WebApplicationContext`] object based on the bean definitions and stores it in the `ServletContext` of the web application. @@ -91,7 +91,7 @@ name or type. Most developers retrieve beans by name and then cast them to one o implemented interfaces. Fortunately, most of the frameworks in this section have simpler ways of looking up beans. -Not only do they make it easy to get beans from a Spring container, but they also let you +Not only do they make it easy to get beans from a Infra container, but they also let you use dependency injection on their controllers. Each web framework section has more detail on its specific integration strategies. @@ -107,29 +107,29 @@ individually usable, e.g. through embedding Mojarra or MyFaces within Tomcat. Please note that recent versions of JSF became closely tied to CDI infrastructure in application servers, with some new JSF functionality only working in such an -environment. Spring's JSF support is not actively evolved anymore and primarily +environment. Infra JSF support is not actively evolved anymore and primarily exists for migration purposes when modernizing older JSF-based applications. -The key element in Spring's JSF integration is the JSF `ELResolver` mechanism. +The key element in Infra JSF integration is the JSF `ELResolver` mechanism. [[jsf-springbeanfaceselresolver]] -=== Spring Bean Resolver +=== Infra Bean Resolver -`SpringBeanFacesELResolver` is a JSF compliant `ELResolver` implementation, +`InfraBeanFacesELResolver` is a JSF compliant `ELResolver` implementation, integrating with the standard Unified EL as used by JSF and JSP. It delegates to -Spring's "business context" `WebApplicationContext` first and then to the +Infra "business context" `WebApplicationContext` first and then to the default resolver of the underlying JSF implementation. -Configuration-wise, you can define `SpringBeanFacesELResolver` in your JSF +Configuration-wise, you can define `InfraBeanFacesELResolver` in your JSF `faces-context.xml` file, as the following example shows: [source,xml,indent=0,subs="verbatim,quotes"] ---- - cn.taketoday.web.jsf.el.SpringBeanFacesELResolver + cn.taketoday.web.jsf.el.InfraBeanFacesELResolver ... @@ -165,7 +165,7 @@ community, which let the project grow and become popular among Java web develope As a successor to the original Struts 1.x, check out Struts 2.x or more recent versions as well as the Struts-provided -https://struts.apache.org/plugins/spring/[Spring Plugin] for built-in Spring integration. +https://struts.apache.org/plugins/spring/[Infra Plugin] for built-in Infra integration. @@ -176,12 +176,12 @@ https://struts.apache.org/plugins/spring/[Spring Plugin] for built-in Spring int https://tapestry.apache.org/[Tapestry] is a "Component oriented framework for creating dynamic, robust, highly scalable web applications in Java." -While Spring has its own xref:web/webmvc.adoc#mvc[powerful web layer], there are a number of unique +While Infra has its own xref:web/webmvc.adoc#mvc[powerful web layer], there are a number of unique advantages to building an enterprise Java application by using a combination of Tapestry -for the web user interface and the Spring container for the lower layers. +for the web user interface and the Infra container for the lower layers. For more information, see Tapestry's dedicated -https://tapestry.apache.org/integrating-with-spring-framework.html[integration module for Spring]. +https://tapestry.apache.org/integrating-with-spring-framework.html[integration module for Infra]. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-client.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-client.adoc index 4f2e321d6e..4edceb4600 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-client.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-client.adoc @@ -20,7 +20,7 @@ See xref:integration/rest-clients.adoc#rest-restclient[`RestClient`] for more de == `RestTemplate` `RestTemplate` is a synchronous client to perform HTTP requests. It is the original -Spring REST client and exposes a simple, template-method API over underlying HTTP client +Infra REST client and exposes a simple, template-method API over underlying HTTP client libraries. See xref:integration/rest-clients.adoc[REST Endpoints] for details. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-functional.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-functional.adoc index 12a33ff77d..730d2a4147 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-functional.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-functional.adoc @@ -2,7 +2,7 @@ = Functional Endpoints [.small]#<># -Spring Web MVC includes WebMvc.fn, a lightweight functional programming model in which functions +Infra Web MVC includes WebMvc.fn, a lightweight functional programming model in which functions are used to route and handle requests and contracts are designed for immutability. It is an alternative to the annotation-based programming model but otherwise runs on the same xref:web/webmvc/mvc-servlet.adoc[DispatcherServlet]. @@ -310,8 +310,8 @@ found. If it is not found, we return a 404 Not Found response. [[webmvc-fn-handler-validation]] === Validation -A functional endpoint can use Spring's xref:web/webmvc/mvc-config/validation.adoc[validation facilities] to -apply validation to the request body. For example, given a custom Spring +A functional endpoint can use Infra xref:web/webmvc/mvc-config/validation.adoc[validation facilities] to +apply validation to the request body. For example, given a custom Infra xref:web/webmvc/mvc-config/validation.adoc[Validator] implementation for a `Person`: [tabs] @@ -350,7 +350,7 @@ public class PersonHandler { Handlers can also use the standard bean validation API (JSR-303) by creating and injecting a global `Validator` instance based on `LocalValidatorFactoryBean`. -See xref:core/validation/beanvalidation.adoc[Spring Validation]. +See xref:core/validation/beanvalidation.adoc[Infra Validation]. @@ -416,7 +416,7 @@ The example shown above also uses two request predicates, as the builder uses Router functions are evaluated in order: if the first route does not match, the second is evaluated, and so on. Therefore, it makes sense to declare more specific routes before general ones. -This is also important when registering router functions as Spring beans, as will +This is also important when registering router functions as Infra beans, as will be described later. Note that this behavior is different from the annotation-based programming model, where the "most specific" controller method is picked automatically. @@ -567,11 +567,11 @@ RouterFunction resources = RouterFunctions.resources("/resources == Running a Server You typically run router functions in a xref:web/webmvc/mvc-servlet.adoc[`DispatcherHandler`]-based setup through the -xref:web/webmvc/mvc-config.adoc[MVC Config], which uses Spring configuration to declare the +xref:web/webmvc/mvc-config.adoc[MVC Config], which uses Infra configuration to declare the components required to process requests. The MVC Java configuration declares the following infrastructure components to support functional endpoints: -* `RouterFunctionMapping`: Detects one or more `RouterFunction` beans in the Spring +* `RouterFunctionMapping`: Detects one or more `RouterFunction` beans in the Infra configuration, xref:core/beans/annotation-config/autowired.adoc#beans-factory-ordered[orders them], combines them through `RouterFunction.andOther`, and routes requests to the resulting composed `RouterFunction`. * `HandlerFunctionAdapter`: Simple adapter that lets `DispatcherHandler` invoke @@ -579,7 +579,7 @@ a `HandlerFunction` that was mapped to a request. The preceding components let functional endpoints fit within the `DispatcherServlet` request processing lifecycle and also (potentially) run side by side with annotated controllers, if -any are declared. It is also how functional endpoints are enabled by the Spring Boot Web +any are declared. It is also how functional endpoints are enabled by the Infra App Web starter. The following example shows a WebFlux Java configuration: diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-test.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-test.adoc index 9a01729f65..ec2fe5167c 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-test.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-test.adoc @@ -1,13 +1,13 @@ [[test]] = 测试 -This section summarizes the options available in `spring-test` for Web MVC applications. +This section summarizes the options available in `today-test` for Web MVC applications. * Servlet API Mocks: Mock implementations of Servlet API contracts for unit testing controllers, filters, and other web components. See xref:testing/unit.adoc#mock-objects-servlet[Servlet API] mock objects for more details. -* TestContext Framework: Support for loading Spring configuration in JUnit and TestNG tests, +* TestContext Framework: Support for loading Infra configuration in JUnit and TestNG tests, including efficient caching of the loaded configuration across test methods and support for loading a `WebApplicationContext` with a `MockServletContext`. See xref:testing/testcontext-framework.adoc[TestContext Framework] for more details. @@ -17,7 +17,7 @@ through the `DispatcherServlet` (that is, supporting annotations), complete with Web MVC infrastructure but without an HTTP server. See xref:testing/spring-mvc-test-framework.adoc[Web MVC Test] for more details. -* Client-side REST: `spring-test` provides a `MockRestServiceServer` that you can use as +* Client-side REST: `today-test` provides a `MockRestServiceServer` that you can use as a mock server for testing client-side code that internally uses the `RestTemplate`. See xref:testing/spring-mvc-test-client.adoc[Client REST Tests] for more details. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-document.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-document.adoc index 50e17cdad9..ec5236c904 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-document.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-document.adoc @@ -1,7 +1,7 @@ [[mvc-view-document]] = PDF and Excel -Spring offers ways to return output other than HTML, including PDF and Excel spreadsheets. +Infra offers ways to return output other than HTML, including PDF and Excel spreadsheets. This section describes how to use those features. @@ -10,7 +10,7 @@ This section describes how to use those features. == Introduction to Document Views An HTML page is not always the best way for the user to view the model output, -and Spring makes it simple to generate a PDF document or an Excel spreadsheet +and Infra makes it simple to generate a PDF document or an Excel spreadsheet dynamically from the model data. The document is the view and is streamed from the server with the correct content type, to (hopefully) enable the client PC to run their spreadsheet or PDF viewer application in response. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-feeds.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-feeds.adoc index 34d2a21235..e82d3e9d2b 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-feeds.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-feeds.adoc @@ -66,7 +66,7 @@ you need to access the Locale. The HTTP response is passed in only for the setti cookies or other HTTP headers. The feed is automatically written to the response object after the method returns. -For an example of creating an Atom view, see Alef Arendsen's Spring Team Blog +For an example of creating an Atom view, see Alef Arendsen's Infra Team Blog {today-tech-site-blog}/2009/03/16/adding-an-atom-view-to-an-application-using-spring-s-rest-support[entry]. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-freemarker.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-freemarker.adoc index 49be20c3a1..213f09d031 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-freemarker.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-freemarker.adoc @@ -62,7 +62,7 @@ returns a view name of `welcome`, the resolver looks for the == FreeMarker Configuration You can pass FreeMarker 'Settings' and 'SharedVariables' directly to the FreeMarker -`Configuration` object (which is managed by Spring) by setting the appropriate bean +`Configuration` object (which is managed by Infra) by setting the appropriate bean properties on the `FreeMarkerConfigurer` bean. The `freemarkerSettings` property requires a `java.util.Properties` object, and the `freemarkerVariables` property requires a `java.util.Map`. The following example shows how to use a `FreeMarkerConfigurer`: @@ -88,10 +88,10 @@ the `Configuration` object. [[mvc-view-freemarker-forms]] == Form Handling -Spring provides a tag library for use in JSPs that contains, among others, a +Infra provides a tag library for use in JSPs that contains, among others, a `` element. This element primarily lets forms display values from form-backing objects and show the results of failed validations from a `Validator` in the -web or business tier. Spring also has support for the same functionality in FreeMarker, +web or business tier. Infra also has support for the same functionality in FreeMarker, with additional convenience macros for generating form input elements themselves. @@ -101,7 +101,7 @@ with additional convenience macros for generating form input elements themselves A standard set of macros are maintained within the `spring-webmvc.jar` file for FreeMarker, so they are always available to a suitably configured application. -Some of the macros defined in the Spring templating libraries are considered internal +Some of the macros defined in the Infra templating libraries are considered internal (private), but no such scoping exists in the macro definitions, making all macros visible to calling code and user templates. The following sections concentrate only on the macros you need to directly call from within your templates. If you wish to view the macro code @@ -159,7 +159,7 @@ wherever possible. They are explained in the next section. Additional convenience macros for FreeMarker simplify both binding and form generation (including validation error display). It is never necessary to use these macros to generate form input fields, and you can mix and match them with simple HTML or direct -calls to the Spring bind macros that we highlighted previously. +calls to the Infra bind macros that we highlighted previously. The following table of available macros shows the FreeMarker Template (FTL) definitions and the parameter list that each takes: @@ -248,7 +248,7 @@ The following sections outline examples of the macros. The `formInput` macro takes the `path` parameter (`command.name`) and an additional `attributes` parameter (which is empty in the upcoming example). The macro, along with all other form -generation macros, performs an implicit Spring bind on the path parameter. The binding +generation macros, performs an implicit Infra bind on the path parameter. The binding remains valid until a new bind occurs, so the `showErrors` macro does not need to pass the path parameter again -- it operates on the field for which a binding was last created. @@ -266,7 +266,7 @@ and `showErrors` macros: The next example shows the output of the form fragment, generating the name field and displaying a validation error after the form was submitted with no value in the field. Validation -occurs through Spring's Validation framework. +occurs through Infra Validation framework. The generated HTML resembles the following example: @@ -366,7 +366,7 @@ user still sees the more user-friendly city names, as follows: Default usage of the form macros described earlier results in HTML elements that are HTML 4.01 compliant and that use the default value for HTML escaping defined in your `web.xml` file, as -used by Spring's bind support. To make the elements be XHTML compliant or to override +used by Infra bind support. To make the elements be XHTML compliant or to override the default HTML escaping value, you can specify two variables in your template (or in your model, where they are visible to your templates). The advantage of specifying them in the templates is that they can be changed to different values later in the @@ -381,7 +381,7 @@ model or context variable named `xhtmlCompliant`, as the following example shows <#assign xhtmlCompliant = true> ---- -After processing this directive, any elements generated by the Spring macros are now XHTML +After processing this directive, any elements generated by the Infra macros are now XHTML compliant. In similar fashion, you can specify HTML escaping per field, as the following example shows: diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-jackson.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-jackson.adoc index 12b25e48a7..db62b1fde7 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-jackson.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-jackson.adoc @@ -2,7 +2,7 @@ = Jackson -Spring offers support for the Jackson JSON library. +Infra offers support for the Jackson JSON library. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-xslt.adoc b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-xslt.adoc index 0e989820a3..dca9ec198d 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-xslt.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc-view/mvc-xslt.adoc @@ -5,11 +5,11 @@ XSLT is a transformation language for XML and is popular as a view technology wi applications. XSLT can be a good choice as a view technology if your application naturally deals with XML or if your model can easily be converted to XML. The following section shows how to produce an XML document as model data and have it transformed with -XSLT in a Spring Web MVC application. +XSLT in a Infra Web MVC application. -This example is a trivial Spring application that creates a list of words in the +This example is a trivial Infra application that creates a list of words in the `Controller` and adds them to the model map. The map is returned, along with the view -name of our XSLT view. See xref:web/webmvc/mvc-controller.adoc[Annotated Controllers] for details of Spring Web MVC's +name of our XSLT view. See xref:web/webmvc/mvc-controller.adoc[Annotated Controllers] for details of Infra Web MVC's `Controller` interface. The XSLT controller turns the list of words into a simple XML document ready for transformation. @@ -18,7 +18,7 @@ document ready for transformation. [[mvc-view-xslt-beandefs]] == Beans -Configuration is standard for a simple Spring web application: The MVC configuration +Configuration is standard for a simple Infra web application: The MVC configuration has to define an `XsltViewResolver` bean and regular MVC annotation configuration. The following example shows how to do so: @@ -68,7 +68,7 @@ public class XsltController { Document document = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument(); Element root = document.createElement("wordList"); - List words = Arrays.asList("Hello", "Spring", "Framework"); + List words = Arrays.asList("Hello", "Infra", "Framework"); for (String word : words) { Element wordNode = document.createElement("word"); Text textNode = document.createTextNode(word); @@ -88,7 +88,7 @@ So far, we have only created a DOM document and added it to the Model map. Note can also load an XML file as a `Resource` and use it instead of a custom DOM document. There are software packages available that automatically 'domify' -an object graph, but, within Spring, you have complete flexibility to create the DOM +an object graph, but, within Infra, you have complete flexibility to create the DOM from your model in any way you choose. This prevents the transformation of XML playing too great a part in the structure of your model data, which is a danger when using tools to manage the DOMification process. @@ -144,7 +144,7 @@ The preceding transform is rendered as the following HTML:

My First Words

  • Hello
    • -
  • Spring
    • +
  • Infra
  • Framework
diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/filters.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/filters.adoc index 3eef16c8ab..c0bae7acdc 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/filters.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/filters.adoc @@ -2,7 +2,7 @@ = Filters -The `spring-web` module provides some useful filters: +The `today-web` module provides some useful filters: * xref:web/webmvc/filters.adoc#filters-http-put[Form Data] * xref:web/webmvc/filters.adoc#filters-shallow-etag[Shallow ETag] @@ -17,7 +17,7 @@ Browsers can submit form data only through HTTP GET or HTTP POST but non-browser use HTTP PUT, PATCH, and DELETE. The Servlet API requires `ServletRequest.getParameter{asterisk}()` methods to support form field access only for HTTP POST. -The `spring-web` module provides `FormContentFilter` to intercept HTTP PUT, PATCH, and DELETE +The `today-web` module provides `FormContentFilter` to intercept HTTP PUT, PATCH, and DELETE requests with a content type of `application/x-www-form-urlencoded`, read the form data from the body of the request, and wrap the `ServletRequest` to make the form data available through the `ServletRequest.getParameter{asterisk}()` family of methods. @@ -60,7 +60,7 @@ In order to support xref:web/webmvc/mvc-ann-async.adoc[asynchronous requests] an filter should be mapped with `DispatcherType.ASYNC` and also `DispatcherType.ERROR`. If using TODAY Framework's `AbstractAnnotationConfigDispatcherServletInitializer` (see xref:web/webmvc/mvc-servlet/container-config.adoc[Servlet Config]) all filters are automatically registered for all dispatch -types. However if registering the filter via `web.xml` or in Spring Boot via a +types. However if registering the filter via `web.xml` or in Infra App via a `FilterRegistrationBean` be sure to include `DispatcherType.ASYNC` and `DispatcherType.ERROR` in addition to `DispatcherType.REQUEST`. @@ -89,7 +89,7 @@ with `DispatcherType.ASYNC` so that the filter can delay and successfully genera ETag to the end of the last async dispatch. If using TODAY Framework's `AbstractAnnotationConfigDispatcherServletInitializer` (see xref:web/webmvc/mvc-servlet/container-config.adoc[Servlet Config]) all filters are automatically registered for all dispatch types. However if registering -the filter via `web.xml` or in Spring Boot via a `FilterRegistrationBean` be sure to include +the filter via `web.xml` or in Infra App via a `FilterRegistrationBean` be sure to include `DispatcherType.ASYNC`. @@ -98,8 +98,8 @@ the filter via `web.xml` or in Spring Boot via a `FilterRegistrationBean` be sur == CORS Web MVC provides fine-grained support for CORS configuration through annotations on -controllers. However, when used with Spring Security, we advise relying on the built-in -`CorsFilter` that must be ordered ahead of Spring Security's chain of filters. +controllers. However, when used with Infra Security, we advise relying on the built-in +`CorsFilter` that must be ordered ahead of Infra Security's chain of filters. See the sections on xref:web/webmvc-cors.adoc[CORS] and the xref:web/webmvc-cors.adoc#mvc-cors-filter[CORS Filter] for more details. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-async.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-async.adoc index 7a94168478..4662d887da 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-async.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-async.adoc @@ -12,7 +12,7 @@ xref:web/webmvc/mvc-ann-async.adoc#mvc-ann-async-sse[SSE] and xref:web/webmvc/mv * Controllers can use reactive clients and return xref:web/webmvc/mvc-ann-async.adoc#mvc-ann-async-reactive-types[reactive types] for response handling. -For an overview of how this differs from Spring WebFlux, see the xref:web/webmvc/mvc-ann-async.adoc#mvc-ann-async-vs-webflux[Async Web MVC compared to WebFlux] section below. +For an overview of how this differs from Infra WebFlux, see the xref:web/webmvc/mvc-ann-async.adoc#mvc-ann-async-vs-webflux[Async Web MVC compared to WebFlux] section below. [[mvc-ann-async-deferredresult]] == `DeferredResult` @@ -160,12 +160,12 @@ the `DeferredResult` is set, an `ASYNC` dispatch (to the same URL) is made, duri controller is mapped again but, rather than invoking it, the `DeferredResult` value is used (as if the controller returned it) to resume processing. -By contrast, Spring WebFlux is neither built on the Servlet API, nor does it need such an +By contrast, Infra WebFlux is neither built on the Servlet API, nor does it need such an asynchronous request processing feature, because it is asynchronous by design. Asynchronous handling is built into all framework contracts and is intrinsically supported through all stages of request processing. -From a programming model perspective, both Web MVC and Spring WebFlux support +From a programming model perspective, both Web MVC and Infra WebFlux support asynchronous and xref:web/webmvc/mvc-ann-async.adoc#mvc-ann-async-reactive-types[Reactive Types] as return values in controller methods. Web MVC even supports streaming, including reactive back pressure. However, individual writes to the response remain blocking (and are performed on a separate thread), unlike WebFlux, @@ -174,7 +174,7 @@ which relies on non-blocking I/O and does not need an extra thread for each writ Another fundamental difference is that Web MVC does not support asynchronous or reactive types in controller method arguments (for example, `@RequestBody`, `@RequestPart`, and others), nor does it have any explicit support for asynchronous and reactive types as model attributes. -Spring WebFlux does support all that. +Infra WebFlux does support all that. Finally, from a configuration perspective the asynchronous request processing feature must be xref:web/webmvc/mvc-ann-async.adoc#mvc-ann-async-configuration[enabled at the Servlet container level]. @@ -266,7 +266,7 @@ emitter.complete(); ====== While SSE is the main option for streaming into browsers, note that Internet Explorer -does not support Server-Sent Events. Consider using Spring's +does not support Server-Sent Events. Consider using Infra xref:web/websocket.adoc[WebSocket messaging] with xref:web/websocket/fallback.adoc[SockJS fallback] transports (including SSE) that target a wide range of browsers. @@ -309,7 +309,7 @@ customize the status and headers of the response. == Reactive Types Web MVC supports use of reactive client libraries in a controller . -This includes the `WebClient` from `spring-webflux` and others, such as Spring Data +This includes the `WebClient` from `spring-webflux` and others, such as Infra Data reactive data repositories. In such scenarios, it is convenient to be able to return reactive types from the controller method. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-rest-exceptions.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-rest-exceptions.adoc index a37949a27f..0f969aa475 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-rest-exceptions.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-ann-rest-exceptions.adoc @@ -34,9 +34,9 @@ already set. "application/problem+json" over "application/json" when rendering a `ProblemDetail`, and also falls back on it if no compatible media type is found. -To enable RFC 7807 responses for Spring WebFlux exceptions and for any +To enable RFC 7807 responses for Infra WebFlux exceptions and for any `ErrorResponseException`, extend `ResponseEntityExceptionHandler` and declare it as an -xref:web/webmvc/mvc-controller/ann-advice.adoc[@ControllerAdvice] in Spring configuration. The handler +xref:web/webmvc/mvc-controller/ann-advice.adoc[@ControllerAdvice] in Infra configuration. The handler has an `@ExceptionHandler` method that handles any `ErrorResponse` exception, which includes all built-in web exceptions. You can add more exception handling methods, and use a protected method to map any exception to a `ProblemDetail`. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-caching.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-caching.adoc index e7d6d6a5dc..cd689c27ce 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-caching.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-caching.adoc @@ -9,7 +9,7 @@ to make a conditional request that may result in a 304 (NOT_MODIFIED) without a if the content has not changed. `ETag` can be seen as a more sophisticated successor to the `Last-Modified` header. -This section describes the HTTP caching-related options that are available in Spring Web MVC. +This section describes the HTTP caching-related options that are available in Infra Web MVC. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-java.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-java.adoc index 954d50a2c9..6fb3af7d2f 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-java.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-java.adoc @@ -3,7 +3,7 @@ `@EnableWebMvc` imports `DelegatingWebMvcConfiguration`, which: -* Provides default Spring configuration for Web MVC applications +* Provides default Infra configuration for Web MVC applications * Detects and delegates to `WebMvcConfigurer` implementations to customize that configuration. For advanced mode, you can remove `@EnableWebMvc` and extend directly from diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-xml.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-xml.adoc index 43226cf623..3c5d87b449 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-xml.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/advanced-xml.adoc @@ -3,7 +3,7 @@ The MVC namespace does not have an advanced mode. If you need to customize a property on a bean that you cannot change otherwise, you can use the `BeanPostProcessor` lifecycle -hook of the Spring `ApplicationContext`, as the following example shows: +hook of the Infra `ApplicationContext`, as the following example shows: [source,java] ---- diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/enable.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/enable.adoc index 143a4740ee..3602f94f78 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/enable.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/enable.adoc @@ -11,7 +11,7 @@ public class WebConfiguration { } ---- -NOTE: When using Spring Boot, you may want to use `@Configuration` classes of type `WebMvcConfigurer` but without `@EnableWebMvc` to keep Spring Boot MVC customizations. See more details in xref:web/webmvc/mvc-config/customize.adoc[the MVC Config API section] and in {today-framework-reference}/web.html#web.servlet.spring-mvc.auto-configuration[the dedicated Spring Boot documentation]. +NOTE: When using Infra App, you may want to use `@Configuration` classes of type `WebMvcConfigurer` but without `@EnableWebMvc` to keep Infra App MVC customizations. See more details in xref:web/webmvc/mvc-config/customize.adoc[the MVC Config API section] and in {today-framework-reference}/web.html#web.servlet.spring-mvc.auto-configuration[the dedicated Infra App documentation]. The preceding example registers a number of Web MVC xref:web/webmvc/mvc-servlet/special-bean-types.adoc[infrastructure beans] and adapts to dependencies diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/interceptors.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/interceptors.adoc index ad711ec4f5..09d04f22b6 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/interceptors.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/interceptors.adoc @@ -20,7 +20,7 @@ NOTE: Interceptors are not ideally suited as a security layer due to the potenti for a mismatch with annotated controller path matching, which can also match trailing slashes and path extensions transparently, along with other path matching options. Many of these options have been deprecated but the potential for a mismatch remains. -Generally, we recommend using Spring Security which includes a dedicated +Generally, we recommend using Infra Security which includes a dedicated https://docs.spring.io/spring-security/reference/servlet/integrations/mvc.html#mvc-requestmatcher[MvcRequestMatcher] to align with Web MVC path matching and also has a security firewall that blocks many unwanted characters in URL paths. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/message-converters.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/message-converters.adoc index 2d5178ec52..aa7880e4b1 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/message-converters.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/message-converters.adoc @@ -7,7 +7,7 @@ replacing the ones used by default, by overriding You can also customize the list of configured message converters at the end by overriding {today-framework-api}/web/servlet/config/annotation/WebMvcConfigurer.html#extendMessageConverters-java.util.List-[`extendMessageConverters()`]. -TIP: In a Spring Boot application, the `WebMvcAutoConfiguration` adds any +TIP: In a Infra App application, the `WebMvcAutoConfiguration` adds any `HttpMessageConverter` beans it detects, in addition to default converters. Hence, in a Boot application, prefer to use the {today-framework-reference}/web.html#web.servlet.spring-mvc.message-converters[HttpMessageConverters] mechanism. Or alternatively, use `extendMessageConverters` to modify message converters diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/static-resources.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/static-resources.adoc index 789d036973..d6247430c7 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/static-resources.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-config/static-resources.adoc @@ -69,7 +69,7 @@ That ensures content-based versions are always computed reliably, based on the u For https://www.webjars.org/documentation[WebJars], versioned URLs like `/webjars/jquery/1.2.0/jquery.min.js` are the recommended and most efficient way to use them. -The related resource location is configured out of the box with Spring Boot (or can be configured +The related resource location is configured out of the box with Infra App (or can be configured manually via `ResourceHandlerRegistry`) and does not require to add the `org.webjars:webjars-locator-core` dependency. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-advice.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-advice.adoc index b33a8d1e31..d09d6d03f0 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-advice.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-advice.adoc @@ -8,7 +8,7 @@ to any controller. Moreover, as of 5.3, `@ExceptionHandler` methods in `@Control can be used to handle exceptions from any `@Controller` or any other handler. `@ControllerAdvice` is meta-annotated with `@Component` and therefore can be registered as -a Spring bean through xref:core/beans/java/instantiating-container.adoc#beans-java-instantiating-container-scan[component scanning] +a Infra bean through xref:core/beans/java/instantiating-container.adoc#beans-java-instantiating-container-scan[component scanning] . `@RestControllerAdvice` is meta-annotated with `@ControllerAdvice` and `@ResponseBody`, and that means `@ExceptionHandler` methods will have their return value rendered via response body message conversion, rather than via HTML views. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-exceptionhandler.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-exceptionhandler.adoc index b7cfe3c3fe..ccf266236e 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-exceptionhandler.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-exceptionhandler.adoc @@ -129,7 +129,7 @@ level, xref:web/webmvc/mvc-servlet/exceptionhandlers.adoc[HandlerExceptionResolv | `jakarta.servlet.ServletRequest`, `jakarta.servlet.ServletResponse` | Choose any specific request or response type (for example, `ServletRequest` or - `HttpServletRequest` or Spring's `MultipartRequest` or `MultipartHttpServletRequest`). + `HttpServletRequest` or Infra `MultipartRequest` or `MultipartHttpServletRequest`). | `jakarta.servlet.http.HttpSession` | Enforces the presence of a session. As a consequence, such an argument is never `null`. + diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/arguments.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/arguments.adoc index f907ab8268..00fac85987 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/arguments.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/arguments.adoc @@ -18,7 +18,7 @@ and others) and is equivalent to `required=false`. | `jakarta.servlet.ServletRequest`, `jakarta.servlet.ServletResponse` | Choose any specific request or response type -- for example, `ServletRequest`, `HttpServletRequest`, - or Spring's `MultipartRequest`, `MultipartHttpServletRequest`. + or Infra `MultipartRequest`, `MultipartHttpServletRequest`. | `jakarta.servlet.http.HttpSession` | Enforces the presence of a session. As a consequence, such an argument is never `null`. @@ -36,9 +36,9 @@ and others) and is equivalent to `required=false`. Note that this argument is not resolved eagerly, if it is annotated in order to allow a custom resolver to resolve it before falling back on default resolution via `HttpServletRequest#getUserPrincipal`. - For example, the Spring Security `Authentication` implements `Principal` and would be injected as such via + For example, the Infra Security `Authentication` implements `Principal` and would be injected as such via `HttpServletRequest#getUserPrincipal`, unless it is also annotated with `@AuthenticationPrincipal` in which case it - is resolved by a custom Spring Security resolver through `Authentication#getPrincipal`. + is resolved by a custom Infra Security resolver through `Authentication#getPrincipal`. | `HttpMethod` | The HTTP method of the request. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/jackson.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/jackson.adoc index 869f99b102..45760b5357 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/jackson.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/jackson.adoc @@ -1,7 +1,7 @@ [[mvc-ann-jackson]] = Jackson JSON -Spring offers support for the Jackson JSON library. +Infra offers support for the Jackson JSON library. [[mvc-ann-jsonview]] == JSON Views diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/modelattrib-method-args.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/modelattrib-method-args.adoc index 98e6494613..ad3fbf588b 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/modelattrib-method-args.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/modelattrib-method-args.adoc @@ -137,9 +137,9 @@ public String processSubmit(@ModelAttribute("pet") Pet pet, BindingResult result ====== You can automatically apply validation after data binding by adding the -`jakarta.validation.Valid` annotation or Spring's `@Validated` annotation. +`jakarta.validation.Valid` annotation or Infra `@Validated` annotation. See xref:core/validation/beanvalidation.adoc[Bean Validation] and -xref:web/webmvc/mvc-config/validation.adoc[Spring validation]. For example: +xref:web/webmvc/mvc-config/validation.adoc[Infra validation]. For example: [tabs] ====== diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/multipart-forms.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/multipart-forms.adoc index 9e83812ce7..976bed570e 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/multipart-forms.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/multipart-forms.adoc @@ -39,7 +39,7 @@ When the `@RequestParam` annotation is declared as a `Map then the map is populated with the multipart files for each given parameter name. NOTE: With Servlet multipart parsing, you may also declare `jakarta.servlet.http.Part` -instead of Spring's `MultipartFile`, as a method argument or collection value type. +instead of Infra `MultipartFile`, as a method argument or collection value type. You can also use multipart content as part of data binding to a xref:web/webmvc/mvc-controller/ann-methods/modelattrib-method-args.adoc[command object]. For example, the form field @@ -121,7 +121,7 @@ public String handle(@RequestPart("meta-data") MetaData metadata, ====== -You can use `@RequestPart` in combination with `jakarta.validation.Valid` or use Spring's +You can use `@RequestPart` in combination with `jakarta.validation.Valid` or use Infra `@Validated` annotation, both of which cause Standard Bean Validation to be applied. By default, validation errors cause a `MethodArgumentNotValidException`, which is turned into a 400 (BAD_REQUEST) response. Alternatively, you can handle validation errors locally diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/requestbody.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/requestbody.adoc index 90e697e540..c36315dd35 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/requestbody.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/requestbody.adoc @@ -21,7 +21,7 @@ public void handle(@RequestBody Account account) { You can use the xref:web/webmvc/mvc-config/message-converters.adoc[Message Converters] option of the xref:web/webmvc/mvc-config.adoc[MVC Config] to configure or customize message conversion. -You can use `@RequestBody` in combination with `jakarta.validation.Valid` or Spring's +You can use `@RequestBody` in combination with `jakarta.validation.Valid` or Infra `@Validated` annotation, both of which cause Standard Bean Validation to be applied. By default, validation errors cause a `MethodArgumentNotValidException`, which is turned into a 400 (BAD_REQUEST) response. Alternatively, you can handle validation errors locally diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/typeconversion.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/typeconversion.adoc index b5eabebfb3..26afd5f9d1 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/typeconversion.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-methods/typeconversion.adoc @@ -9,7 +9,7 @@ For such cases, type conversion is automatically applied based on the configured By default, simple types (`int`, `long`, `Date`, and others) are supported. You can customize type conversion through a `WebDataBinder` (see xref:web/webmvc/mvc-controller/ann-initbinder.adoc[`DataBinder`]) or by registering `Formatters` with the `FormattingConversionService`. -See xref:core/validation/format.adoc[Spring Field Formatting]. +See xref:core/validation/format.adoc[Infra Field Formatting]. A practical issue in type conversion is the treatment of an empty String source value. Such a value is treated as missing if it becomes `null` as a result of type conversion. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-requestmapping.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-requestmapping.adoc index dff74ccd7d..c30a0c59dd 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-requestmapping.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-requestmapping.adoc @@ -69,12 +69,12 @@ class PersonController { `PathContainer`. Designed for web use, this solution deals effectively with encoding and path parameters, and matches efficiently. * `AntPathMatcher` -- match String patterns against a String path. This is the original -solution also used in Spring configuration to select resources on the classpath, on the +solution also used in Infra configuration to select resources on the classpath, on the filesystem, and other locations. It is less efficient and the String path input is a challenge for dealing effectively with encoding and other issues with URLs. `PathPattern` is the recommended solution for web applications and it is the only choice in -Spring WebFlux. It was enabled for use in Web MVC from version 5.3 and is enabled by +Infra WebFlux. It was enabled for use in Web MVC from version 5.3 and is enabled by default from version 6.0. See xref:web/webmvc/mvc-config/path-matching.adoc[MVC config] for customizations of path matching options. @@ -447,7 +447,7 @@ In addition to simplifying client code, there are also cases where an HTTP Inter may be a convenient way for servers to expose their API for client access. This leads to increased coupling between client and server and is often not a good choice, especially for public API's, but may be exactly the goal for an internal API. -It is an approach commonly used in Spring Cloud, and it is why `@HttpExchange` is +It is an approach commonly used in Infra Cloud, and it is why `@HttpExchange` is supported as an alternative to `@RequestMapping` for server side handling in controller classes. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-validation.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-validation.adoc index cc3d2242aa..f074586acc 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-validation.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann-validation.adoc @@ -10,7 +10,7 @@ First, resolvers for xref:web/webmvc/mvc-controller/ann-methods/modelattrib-method-args.adoc[@ModelAttribute], xref:web/webmvc/mvc-controller/ann-methods/requestbody.adoc[@RequestBody], and xref:web/webmvc/mvc-controller/ann-methods/multipart-forms.adoc[@RequestPart] method -parameters perform validation if the parameter has Jakarta's `@Valid` or Spring's +parameters perform validation if the parameter has Jakarta's `@Valid` or Infra `@Validated` annotation, and raise `MethodArgumentNotValidException` if necessary. Alternatively, you can handle the errors in the controller method by adding an `Errors` or `BindingResult` method parameter immediately after the validated one. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann.adoc index c77f8a40e2..db89cfc4d8 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-controller/ann.adoc @@ -1,9 +1,9 @@ [[mvc-ann-controller]] = Declaration -You can define controller beans by using a standard Spring bean definition in the +You can define controller beans by using a standard Infra bean definition in the Servlet's `WebApplicationContext`. The `@Controller` stereotype allows for auto-detection, -aligned with Spring general support for detecting `@Component` classes in the classpath +aligned with Infra general support for detecting `@Component` classes in the classpath and auto-registering bean definitions for them. It also acts as a stereotype for the annotated class, indicating its role as a web component. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet.adoc index cb421f56ec..d3d33b1bf6 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet.adoc @@ -8,7 +8,7 @@ This model is flexible and supports diverse workflows. The `DispatcherServlet`, as any `Servlet`, needs to be declared and mapped according to the Servlet specification by using Java configuration or in `web.xml`. -In turn, the `DispatcherServlet` uses Spring configuration to discover +In turn, the `DispatcherServlet` uses Infra configuration to discover the delegate components it needs for request mapping, view resolution, exception handling, xref:web/webmvc/mvc-servlet/special-bean-types.adoc[and more]. @@ -27,7 +27,7 @@ public class MyWebApplicationInitializer implements WebApplicationInitializer { @Override public void onStartup(ServletContext servletContext) { - // Load Spring web application configuration + // Load Infra web application configuration AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext(); context.register(AppConfig.class); @@ -84,12 +84,12 @@ The following example of `web.xml` configuration registers and initializes the ` ---- -NOTE: Spring Boot follows a different initialization sequence. Rather than hooking into -the lifecycle of the Servlet container, Spring Boot uses Spring configuration to +NOTE: Infra App follows a different initialization sequence. Rather than hooking into +the lifecycle of the Servlet container, Infra App uses Infra configuration to bootstrap itself and the embedded Servlet container. `Filter` and `Servlet` declarations -are detected in Spring configuration and registered with the Servlet container. +are detected in Infra configuration and registered with the Servlet container. For more details, see the -{today-framework-reference}/web.html#web.servlet.embedded-container[Spring Boot documentation]. +{today-framework-reference}/web.html#web.servlet.embedded-container[Infra App documentation]. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/config.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/config.adoc index 36d20c35dc..0ff01015a7 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/config.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/config.adoc @@ -12,7 +12,7 @@ In most cases, the xref:web/webmvc/mvc-config.adoc[MVC Config] is the best start beans in either Java or XML and provides a higher-level configuration callback API to customize it. -NOTE: Spring Boot relies on the MVC Java configuration to configure Web MVC and +NOTE: Infra App relies on the MVC Java configuration to configure Web MVC and provides many extra convenient options. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/container-config.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/container-config.adoc index ef3fad5dae..5f6d9c3725 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/container-config.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/container-config.adoc @@ -37,7 +37,7 @@ An abstract base class implementation of `WebApplicationInitializer` named `DispatcherServlet` by overriding methods to specify the servlet mapping and the location of the `DispatcherServlet` configuration. -This is recommended for applications that use Java-based Spring configuration, as the +This is recommended for applications that use Java-based Infra configuration, as the following example shows: [tabs] @@ -66,7 +66,7 @@ public class MyWebAppInitializer extends AbstractAnnotationConfigDispatcherServl ---- ====== -If you use XML-based Spring configuration, you should extend directly from +If you use XML-based Infra configuration, you should extend directly from `AbstractDispatcherServletInitializer`, as the following example shows: [tabs] diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/exceptionhandlers.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/exceptionhandlers.adoc index b583fa5ba3..6d594ca8b5 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/exceptionhandlers.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/exceptionhandlers.adoc @@ -35,7 +35,7 @@ The following table lists the available `HandlerExceptionResolver` implementatio == Chain of Resolvers You can form an exception resolver chain by declaring multiple `HandlerExceptionResolver` -beans in your Spring configuration and setting their `order` properties as needed. +beans in your Infra configuration and setting their `order` properties as needed. The higher the order property, the later the exception resolver is positioned. The contract of `HandlerExceptionResolver` specifies that it can return: diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/handlermapping-path.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/handlermapping-path.adoc index 0833e57f9e..112590d933 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/handlermapping-path.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/handlermapping-path.adoc @@ -29,7 +29,7 @@ Fortunately the default Servlet mapping `"/"` is a good choice. However, there i an issue in that the `requestURI` needs to be decoded to make it possible to compare to controller mappings. This is again undesirable because of the potential to decode reserved characters that alter the path structure. If such characters are not expected, -then you can reject them (like the Spring Security HTTP firewall), or you can configure +then you can reject them (like the Infra Security HTTP firewall), or you can configure `UrlPathHelper` with `urlDecode=false` but controller mappings will need to match to the encoded path which may not always work well. Furthermore, sometimes the `DispatcherServlet` needs to share the URL space with another Servlet and may need to diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/localeresolver.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/localeresolver.adoc index 97801482c8..83677bc119 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/localeresolver.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/localeresolver.adoc @@ -1,7 +1,7 @@ [[mvc-localeresolver]] = Locale -Most parts of Spring's architecture support internationalization, as the Spring web +Most parts of Infra architecture support internationalization, as the Infra web MVC framework does. `DispatcherServlet` lets you automatically resolve messages by using the client's locale. This is done with `LocaleResolver` objects. @@ -17,7 +17,7 @@ based on a parameter in the request). Locale resolvers and interceptors are defined in the `cn.taketoday.web.servlet.i18n` package and are configured in your application context in the normal way. The following selection of locale resolvers is included in -Spring. +Infra. * xref:web/webmvc/mvc-servlet/localeresolver.adoc#mvc-timezone[Time Zone] * xref:web/webmvc/mvc-servlet/localeresolver.adoc#mvc-localeresolver-acceptheader[Header Resolver] @@ -35,7 +35,7 @@ resolvers provide a richer `LocaleContext`, which may include time zone informat When available, the user's `TimeZone` can be obtained by using the `RequestContext.getTimeZone()` method. Time zone information is automatically used -by any Date/Time `Converter` and `Formatter` objects that are registered with Spring's +by any Date/Time `Converter` and `Formatter` objects that are registered with Infra `ConversionService`. @@ -103,7 +103,7 @@ Servlet container's `HttpSession`. As a consequence, those settings are temporar for each session and are, therefore, lost when each session ends. Note that there is no direct relationship with external session management mechanisms, -such as the Spring Session project. This `SessionLocaleResolver` evaluates and +such as the Infra Session project. This `SessionLocaleResolver` evaluates and modifies the corresponding `HttpSession` attributes against the current `HttpServletRequest`. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/multipart.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/multipart.adoc index ee0c1a15ac..f63222ecac 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/multipart.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/multipart.adoc @@ -8,7 +8,7 @@ Note that the outdated `CommonsMultipartResolver` based on Apache Commons FileUp not available anymore, as of TODAY Framework 6.0 with its new Servlet 5.0+ baseline. To enable multipart handling, you need to declare a `MultipartResolver` bean in your -`DispatcherServlet` Spring configuration with a name of `multipartResolver`. +`DispatcherServlet` Infra configuration with a name of `multipartResolver`. The `DispatcherServlet` detects it and applies it to the incoming request. When a POST with a content type of `multipart/form-data` is received, the resolver parses the content wraps the current `HttpServletRequest` as a `MultipartHttpServletRequest` to diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/special-bean-types.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/special-bean-types.adoc index d16b76ca6c..9d300697b9 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/special-bean-types.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/special-bean-types.adoc @@ -2,7 +2,7 @@ = Special Bean Types The `DispatcherServlet` delegates to special beans to process requests and render the -appropriate responses. By "`special beans`" we mean Spring-managed `Object` instances that +appropriate responses. By "`special beans`" we mean Infra-managed `Object` instances that implement framework contracts. Those usually come with built-in contracts, but you can customize their properties and extend or replace them. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/themeresolver.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/themeresolver.adoc index 5c24b98a67..9fcb1892be 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/themeresolver.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/themeresolver.adoc @@ -1,7 +1,7 @@ [[mvc-themeresolver]] = Themes -You can apply Spring Web MVC framework themes to set the overall look-and-feel of your +You can apply Infra Web MVC framework themes to set the overall look-and-feel of your application, thereby enhancing user experience. A theme is a collection of static resources, typically style sheets and images, that affect the visual style of the application. @@ -66,7 +66,7 @@ After you define themes, as described in the xref:web/webmvc/mvc-servlet/themere you decide which theme to use. The `DispatcherServlet` looks for a bean named `themeResolver` to find out which `ThemeResolver` implementation to use. A theme resolver works in much the same way as a `LocaleResolver`. It detects the theme to use for a particular request and can also -alter the request's theme. The following table describes the theme resolvers provided by Spring: +alter the request's theme. The following table describes the theme resolvers provided by Infra: [[mvc-theme-resolver-impls-tbl]] .ThemeResolver implementations @@ -85,7 +85,7 @@ alter the request's theme. The following table describes the theme resolvers pro | The selected theme is stored in a cookie on the client. |=== -Spring also provides a `ThemeChangeInterceptor` that lets theme changes on every +Infra also provides a `ThemeChangeInterceptor` that lets theme changes on every request with a simple request parameter. diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/viewresolver.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/viewresolver.adoc index 2014eeb1e9..ad5312b774 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/viewresolver.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-servlet/viewresolver.adoc @@ -62,7 +62,7 @@ the only way to figure out if a JSP exists is to perform a dispatch through `RequestDispatcher`. Therefore, you must always configure an `InternalResourceViewResolver` to be last in the overall order of view resolvers. -Configuring view resolution is as simple as adding `ViewResolver` beans to your Spring +Configuring view resolution is as simple as adding `ViewResolver` beans to your Infra configuration. The xref:web/webmvc/mvc-config.adoc[MVC Config] provides a dedicated configuration API for xref:web/webmvc/mvc-config/view-resolvers.adoc[View Resolvers] and for adding logic-less xref:web/webmvc/mvc-config/view-controller.adoc[View Controllers] which are useful for HTML template diff --git a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-uri-building.adoc b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-uri-building.adoc index e5f36401bb..4c4b2f9510 100644 --- a/infra-docs/modules/ROOT/pages/web/webmvc/mvc-uri-building.adoc +++ b/infra-docs/modules/ROOT/pages/web/webmvc/mvc-uri-building.adoc @@ -200,7 +200,7 @@ Given the preceding controller, you can prepare a link from a JSP, as follows: Get Address ---- -The preceding example relies on the `mvcUrl` function declared in the Spring tag library +The preceding example relies on the `mvcUrl` function declared in the Infra tag library (that is, META-INF/spring.tld), but it is easy to define your own function or prepare a similar one for other templating technologies. diff --git a/infra-docs/modules/ROOT/pages/web/websocket/server.adoc b/infra-docs/modules/ROOT/pages/web/websocket/server.adoc index 24664b2f9c..251c44be8e 100644 --- a/infra-docs/modules/ROOT/pages/web/websocket/server.adoc +++ b/infra-docs/modules/ROOT/pages/web/websocket/server.adoc @@ -41,7 +41,7 @@ public class WebSocketConfiguration implements WebSocketConfigurer { ---- The preceding example is for use in Web MVC applications and should be included in the configuration of a xref:web/webmvc/mvc-servlet.adoc[`DispatcherServlet`]. -However, Spring's WebSocket support does not depend on Web MVC. +However, Infra WebSocket support does not depend on Web MVC. It is relatively simple to integrate a `WebSocketHandler` into other HTTP-serving environments with the help of {today-framework-api}/web/socket/server/support/WebSocketHttpRequestHandler.html[`WebSocketHttpRequestHandler`]. @@ -77,7 +77,7 @@ An application may also need to use this option if it needs to configure a custo Both the Java configuration and XML namespace make it possible to configure a custom `HandshakeHandler`. -TIP: Spring provides a `WebSocketHandlerDecorator` base class that you can use to decorate a `WebSocketHandler` with additional behavior. +TIP: Infra provides a `WebSocketHandlerDecorator` base class that you can use to decorate a `WebSocketHandler` with additional behavior. Logging and exception handling implementations are provided and added by default when using the WebSocket Java configuration or XML namespace. The `ExceptionWebSocketHandlerDecorator` catches all uncaught exceptions that arise from any `WebSocketHandler` method and closes the WebSocket session with status `1011`, which indicates a server error. @@ -86,7 +86,7 @@ The `ExceptionWebSocketHandlerDecorator` catches all uncaught exceptions that ar [[websocket-server-deployment]] == Deployment -The Spring WebSocket API is easy to integrate into a Web MVC application where the `DispatcherServlet` serves both HTTP WebSocket handshake and other HTTP requests. +The Infra WebSocket API is easy to integrate into a Web MVC application where the `DispatcherServlet` serves both HTTP WebSocket handshake and other HTTP requests. It is also easy to integrate into other HTTP processing scenarios by invoking `WebSocketHttpRequestHandler`. This is convenient and easy to understand. However, special considerations apply with regards to JSR-356 runtimes. @@ -97,9 +97,9 @@ The other is a registration API to use at Servlet container initialization. Neither of these mechanism makes it possible to use a single "`front controller`" for all HTTP processing -- including WebSocket handshake and all other HTTP requests -- such as Web MVC's `DispatcherServlet`. -This is a significant limitation of JSR-356 that Spring's WebSocket support addresses with server-specific `RequestUpgradeStrategy` implementations even when running in a JSR-356 runtime. +This is a significant limitation of JSR-356 that Infra WebSocket support addresses with server-specific `RequestUpgradeStrategy` implementations even when running in a JSR-356 runtime. Such strategies currently exist for Tomcat, Jetty, GlassFish, WebLogic, WebSphere, and Undertow (and WildFly). -As of Jakarta WebSocket 2.1, a standard request upgrade strategy is available which Spring chooses on Jakarta EE 10 based web containers such as Tomcat 10.1 and Jetty 12. +As of Jakarta WebSocket 2.1, a standard request upgrade strategy is available which Infra chooses on Jakarta EE 10 based web containers such as Tomcat 10.1 and Jetty 12. A secondary consideration is that Servlet containers with JSR-356 support are expected to perform a `ServletContainerInitializer` (SCI) scan that can slow down application startup -- in some cases, dramatically. If a significant impact is observed after an upgrade to a Servlet container version with JSR-356 support, it should be possible to selectively enable or disable web fragments (and SCI scanning) through the use of the `` element in `web.xml`, as the following example shows: @@ -118,8 +118,8 @@ If a significant impact is observed after an upgrade to a Servlet container vers ---- -You can then selectively enable web fragments by name, such as Spring's own -`SpringServletContainerInitializer` that provides support for the Servlet 3 Java initialization API. +You can then selectively enable web fragments by name, such as Infra own +`InfraServletContainerInitializer` that provides support for the Servlet 3 Java initialization API. The following example shows how to do so: [source,xml,indent=0,subs="verbatim,quotes,attributes"]