|
For the latest stable version, please use Spring Integration 6.4.1! |
Resource Support
The resource inbound channel adapter builds upon Spring’s Resource abstraction to support greater flexibility across a variety of actual types of underlying resources, such as a file, a URL, or a class path resource.
Therefore, it is similar to but more generic than the file inbound channel adapter.
Resource Inbound Channel Adapter
The resource inbound channel adapter is a polling adapter that creates a Message whose payload is a collection of Resource objects.
Resource objects are resolved based on the pattern specified by the pattern attribute.
The collection of resolved Resource objects is then sent as a payload within a Message to the adapter’s channel.
That is one major difference between resource inbound channel adapter and file inbound channel adapter: The latter buffers File objects and sends a single File object per Message.
The following example shows a simple configuration that finds all files that end with the 'properties' extension in the things.thing1 package available on the classpath and sends them as the payload of a Message to the channel named ‘resultChannel’:
<int:resource-inbound-channel-adapter id="resourceAdapter"
channel="resultChannel"
pattern="classpath:things/thing1/*.properties">
<int:poller fixed-rate="1000"/>
</int:resource-inbound-channel-adapter>The resource inbound channel adapter relies on the org.springframework.core.io.support.ResourcePatternResolver strategy interface to resolve the provided pattern.
It defaults to an instance of the current ApplicationContext.
However, you can provide a reference to an instance of your own implementation of ResourcePatternResolver by setting the pattern-resolver attribute, as the following example shows:
<int:resource-inbound-channel-adapter id="resourceAdapter"
channel="resultChannel"
pattern="classpath:things/thing1/*.properties"
pattern-resolver="myPatternResolver">
<int:poller fixed-rate="1000"/>
</int:resource-inbound-channel-adapter>
<bean id="myPatternResolver" class="org.example.MyPatternResolver"/>You may have a use case where you need to further filter the collection of resources resolved by the ResourcePatternResolver.
For example, you may want to prevent resources that were already resolved from appearing in a collection of resolved resources ever again.
On the other hand, your resources might be updated rather often, and you do want them to be picked up again.
In other words, both defining an additional filter and disabling filtering altogether are valid use cases.
You can provide your own implementation of the org.springframework.integration.util.CollectionFilter strategy interface, as the following example shows:
public interface CollectionFilter<T> {
Collection<T> filter(Collection<T> unfilteredElements);
}The CollectionFilter receives a collection of un-filtered elements (which are Resource objects in the preceding example), and it returns a collection of filtered elements of that same type.
If you define the adapter with XML but you do not specify a filter reference, the resource inbound channel adapter uses a default implementation of CollectionFilter.
The implementation class of that default filter is org.springframework.integration.util.AcceptOnceCollectionFilter.
It remembers the elements passed in the previous invocation in order to avoid returning those elements more than once.
To inject your own implementation of CollectionFilter instead, use the filter attribute, as the following example shows:
<int:resource-inbound-channel-adapter id="resourceAdapter"
channel="resultChannel"
pattern="classpath:things/thing1/*.properties"
filter="myFilter">
<int:poller fixed-rate="1000"/>
</int:resource-inbound-channel-adapter>
<bean id="myFilter" class="org.example.MyFilter"/>If you do not need any filtering and want to disable even the default CollectionFilter strategy, provide an empty value for the filter attribute (for example, filter="")
