Skip to content

Add ResourcesItemReaderBuilder with support for a file pattern - #5488

Closed
benelog wants to merge 1 commit into
spring-projects:mainfrom
benelog:GH-5487
Closed

benelog wants to merge 1 commit into
spring-projects:mainfrom
benelog:GH-5487

Conversation

@benelog

@benelog benelog commented Aug 9, 2026

Copy link
Copy Markdown
Contributor

Resolves #5487

The new ResourcesItemReaderBuilder follows the structure of the existing builders in the same package. Since ResourcesItemReader has no saveState or strict properties, the builder only exposes resources(Resource...), filesPattern(String) and name(String). The name is optional because the reader falls back to a class-name-based execution context key.

The filesPattern(String) method has the same name and semantics as the one proposed for MultiResourceItemReaderBuilder in #5071: the pattern is resolved by PathMatchingResourcePatternResolver with a "file:" prefix at build time. The test resource files are named resource1.txt and resource2.txt so that they do not clash with the test1.txt/test2.txt files added by #5071 in the same directory, in case both PRs get merged.

ResourcesItemReader was the only reader in the item.file package
without a builder, and resolving a file pattern into resources was
left to the user in Java configuration.

This commit adds ResourcesItemReaderBuilder with resources(),
filesPattern() and name() methods. The filesPattern() method resolves
the pattern with PathMatchingResourcePatternResolver, consistent with
the method of the same name proposed for MultiResourceItemReaderBuilder.

Resolves spring-projects#5487

Signed-off-by: Sanghyuk Jung <sanghyuk.jung@navercorp.com>
fmbenhassine added a commit that referenced this pull request Sep 16, 2026
* Replace `filesPattern(String)` with an overload of `resources(String...)`, consistent with `MultiResourceItemReaderBuilder`
* Resolve location patterns without forcing a `file:` prefix, letting callers pick the prefix (`file:`, `classpath:`, `classpath*:`, etc.)
* Drop the separate `filesPattern` field and its build-time precedence logic, populating the existing `resources` field instead
* Update the added tests to use the new method signature
* Document `ResourcesItemReader` in the reference docs and add a section to the 6.1 what's new page
@fmbenhassine

Copy link
Copy Markdown
Contributor

LGTM 👍 The only thing I have to say is to keep the builder agnostic to resources type, and let the user choose the prefix. For that, we can use a method overload rather than a new method (similar to #5071)

Merged as 1209216, and refined in 930ef88.

Thank you for all your contributions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a builder for ResourcesItemReader with support for specifying resources via a pattern

2 participants