Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

GH-9373: Document Spring nature of Spring Integration classes

Browse Source 
Fixes: #9373
This commit is contained in:
Artem Bilan
2024-08-09 10:14:24 -04:00
parent 02b58277f4
commit 1e86856ba7
1 changed files with 9 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/reference/antora/modules/ROOT/pages/overview.adoc
View File

@@ -427,7 +427,14 @@ See xref:configuration/annotations.adoc[Annotation Support] for more information
[[programming-considerations]]
=== Programming Considerations
You should use plain old java objects (POJOs) whenever possible and only expose the framework in your code when absolutely necessary.
Most classes in Spring Integration (unless stated otherwise) must be declared as beans in the application context and as singletons.
That means instances of these classes are thread-safe and their lifecycle and connection with other components are managed by Spring dependency injection container.
The utility and builder classes (`JacksonJsonUtils, `MessageBuilder`, `ExpressionEvalMap`, `IntegrationReactiveUtils` etc.) can be used directly in the Java code.
However, Java DSL factories and `IntegrationComponentSpec` implementation results still have to be registered as beans into the application context.
The `Session` abstraction, present in many modules, is not thread-safe, typically created by the `Factory` pattern implementation, and used from thread-safe `Template` pattern.
See, for example, `SftpRemoteFileTemplate` and its relationship with the `DefaultSftpSessionFactory`.
You should use plain old java objects (POJOs) whenever possible (for message handling in target logic) and only expose the framework in your code when absolutely necessary.
See xref:overview.adoc#pojo-invocation[POJO Method invocation] for more information.
If you do expose the framework to your classes, there are some considerations that need to be taken into account, especially during application startup:
@@ -457,7 +464,7 @@ These files also need to be merged.
IMPORTANT: https://docs.spring.io/spring-boot/docs/current/reference/html/executable-jar.html[Spring Boot's executable jar mechanism] takes a different approach, in that it nests the jars, thus retaining each `spring.factories` file on the class path.
So, with a Spring Boot application, nothing more is needed if you use its default executable jar format.
Even if you do not use Spring Boot, you can still use the tooling provided by Boot to enhance the shade plugin by adding transformers for the above mentioned files.
Even if you do not use Spring Boot, you can still use the tooling provided by Boot to enhance the shade plugin by adding transformers for the files mentioned above.
The following example shows how to configure the plugin:
.pom.xml