Spring Integration Samples: 50+ Runnable Examples for Messaging Architecture

What Spring Integration Samples Is, and What It Is Not

The README opens with a direct statement of intent: the repository "provides 50+ samples to help you learn Spring Integration." That is the whole scope. It is a collection of small applications, each demonstrating one or a few components of the Spring Integration framework, organized so that a reader can find the concept they are stuck on and read the code that makes it work.

The audience is developers who have decided to use Spring Integration and now need to see a working configuration. The Basic category is described as "a good place to get started," aimed at people who want to know how to wire a Service Activator to a Channel, apply a Gateway, or use the MAIL or XML module. Intermediate targets developers past that point, dealing with error handling or an Aggregator where messages may never arrive. Advanced, Applications and DSL sit above those.

It is not a library you add to a build. There is no published artifact for the samples themselves. The repository is a Gradle multi-project build you clone and import, and the code exists to be read and run. Treating it as a dependency would be a category error.

How the Repository Is Organized and How a Sample Runs

The top level holds five category directories (basic, intermediate, advanced, applications, dsl) plus build.gradle, settings.gradle, gradle.properties, the Gradle wrapper scripts and a src directory. Each category has its own README.md with a description, and each individual sample has one explaining how to run it. That nested documentation is the navigation mechanism, and skipping it is the most common way to waste time here.

The samples are Gradle subprojects. The README says to open the project in an IDE using its import option against the build.gradle file in the root project directory. Running a sample means running its main class or its tests through Gradle, which pulls the Spring Integration modules that sample needs. The categories are not layers you build on; they are difficulty tiers. A Basic sample such as file or jdbc is self-contained, and nothing in intermediate depends on it.

The component coverage is broad and named explicitly in the README. Basic lists AMQP adapters, the control bus, the enricher, RSS/ATOM feed, file adapters with polling, FTP, HTTP inbound and outbound gateways, JDBC, JMS, JMX, JPA, IMAP and POP3 mail, MQTT, MongoDB, SFTP, several TCP variants, Twitter adapters, web service gateways, XML with an XPath splitter and router, XMPP, and zip file manipulation. Intermediate adds an asynchronous gateway, a dynamic poller with a custom Trigger, error handling, sequential versus concurrent file processing, and mail attachments. That spread is the reason the repository stays useful: when you need to see how an SFTP inbound adapter is configured, there is a sample for it.

Cloning It and Running the Hello World Flow

The README does not give a clone command, and it does not document a Gradle run task for the samples, so this section cannot supply one. What the README does state is the workflow for opening the project: use the IDE's import option against the build.gradle file in the root project directory. That is the documented starting point.

The helloworld sample under basic is the smallest entry point; the README describes it as "a basic message flow (using Channel, ServiceActivator, QueueChannel)." Read basic/helloworld/README.md before doing anything else, because each sample documents its own run instructions and the top-level README does not repeat them. Whatever command that file gives is the one to use.

If the build fails immediately with a Java version error, the cause is the requirement stated in the README's note: the project now requires Java 17 or above. Check that before debugging anything else.

On the version question, the main branch requires Spring Integration 6.0 or above, and the README points readers to the 5.5.x and other branches for samples running against earlier versions. If your application is on Spring Integration 5.x, cloning main and copying configuration will produce code that does not compile against your framework.

The Version and Branch Trap

The single most consequential line in the README is the note that the main branch requires Spring Integration 6.0 or above, with 5.5.x and other branches carrying the older samples. This is a real limitation for anyone maintaining a legacy application. The samples on main use the current API surface, and Spring Integration has changed enough across the 5.x to 6.x boundary that a copied bean definition or DSL fragment may not compile.

The second constraint is Java 17 or above. Older projects on Java 8 or 11 cannot run these samples unmodified, and the README offers no downgrade path beyond switching branches. There is no compatibility matrix in the README, no table mapping sample names to framework versions. You determine compatibility by reading the branch and the sample's own README, not by consulting a document that does not exist.

A third gap: the README lists no releases. For a samples repository that is not surprising, since there is nothing to release, but it means there is no changelog telling you what changed between visits. If you cloned this a year ago and return now, the diff is your changelog.

Samples Versus Spring Integration Extensions

The README names a sibling project, Spring Integration Extensions, and tells readers to check it for additional samples. The difference is scope. This repository covers the core framework and the modules that ship with it: file, FTP, SFTP, JMS, AMQP, JDBC, JPA, mail, TCP, HTTP, MQTT, MongoDB, XML and the rest. Extensions is where community-contributed adapters and components live, so if you are looking for a sample of an integration that is not in the framework's own module set, this repository is the wrong place and the README says so explicitly.

Within the core set, the categorization is the other axis to understand. A developer looking for error handling will not find it in basic, because basic is deliberately minimal; the README places error handling in intermediate. The same applies to the asynchronous gateway and the dynamic poller. Picking the wrong tier does not mean the sample is missing, it means you looked in the wrong directory.

The README also credits a community sample project by Xavier Padró under a separate heading. That is a pointer outward, not part of this repository's contents, and the README gives no detail about what it contains.

Where the Samples Stop Being Enough

A sample proves a configuration works in isolation. It does not show you how that configuration behaves when the broker is down, when a poller falls behind, or when two adapters contend for the same resource. The README's own description of the intermediate category acknowledges this boundary: it targets developers who need guidance on "how to handle errors in various scenarios" or "how to properly configure an Aggregator for the situations where some messages might not ever arrive." The errorhandling sample demonstrates the framework's error handling capabilities, but the README does not claim it covers every failure mode of a production flow.

There is also no deployment guidance. Nothing in the README describes packaging a sample as a service, running it in a container, or scaling it. These are demonstrations, and the code reflects that: minimal configuration, no operational concerns, no tuning.

Finally, the samples are not a substitute for the framework documentation. They show one way to wire a component, not the full option set. If a sample uses a default you need to change, the sample will not tell you what the alternatives are.

Maintenance Status and What It Costs to Keep Up

The repository is not archived, and the last push was on 2026-07-28. That is recent enough that the main branch tracks current Spring Integration, and the README's version note about 6.0 or above is consistent with that. For a teaching repository, this matters more than it would for a library: samples that lag the framework teach outdated APIs, and this one has not lagged.

The upgrade cost falls on you, not on the project. Because there is no artifact to depend on, there is no version to bump. What you copy into your application is your responsibility from the moment you copy it. When Spring Integration moves to a new major version, the samples will move with it on main, and your copied fragments will not. That is the trade-off of learning from samples rather than from a library.

The license is not identified in the repository metadata, so this article cannot state terms. Before reusing sample code in a product, check the repository's own license file or the Spring project's licensing page rather than assuming the samples carry the same terms as the framework.

Editorial conclusion

Adopt this repository if you are learning Spring Integration or need a working starting point for an adapter such as file, FTP, JMS or TCP. Do not adopt it as a dependency, and do not expect it to cover Spring Boot auto-configuration, because the README describes the samples as standalone demos. Before you copy anything, open the sample's own README.md, confirm your Spring Integration version is 6.0 or above, and check that the branch you cloned matches your framework version, since the main branch requires 6.0 or above while earlier versions live on the 5.5.x and other branches.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. spring-projects/spring-integration-samples on GitHub