diff --git a/docs/src/reference/docbook/content-enrichment.xml b/docs/src/reference/docbook/content-enrichment.xml
index 2e6660ff84..b9b363327e 100644
--- a/docs/src/reference/docbook/content-enrichment.xml
+++ b/docs/src/reference/docbook/content-enrichment.xml
@@ -81,7 +81,7 @@
As you go through the manual you will see that as an added convenience
- Spring Integration provides adapter specific Header Enrichers (e.g., WS, XMPP, etc.)
+ Spring Integration provides adapter specific Header Enrichers (e.g., MAIL, XMPP, etc.)
diff --git a/docs/src/reference/docbook/feed.xml b/docs/src/reference/docbook/feed.xml
index f897e0d2e7..4badba3890 100644
--- a/docs/src/reference/docbook/feed.xml
+++ b/docs/src/reference/docbook/feed.xml
@@ -3,12 +3,78 @@
xmlns:xlink="http://www.w3.org/1999/xlink">
Feed Adapter
- Spring Integration provides support for Feed (RSS, Atom)
+ Spring Integration provides support for Syndication via Feed Adapters
Introduction
- TODO
+ As we know Web syndication is a form of syndication where material such as news items, press releases that is
+ available to any website is also made available via we feeds such as RSS, ATOM etc.
+
+
+ Spring integration provides support for Web Syndication via FEED adapter which comes with a convenient
+ namespace-based configuration.
+ To configure FEED namespace include the following elements into the headers of your XML configuration file:
+
+
+
+
+ Feed Inbound Channel Adapter
+
+ The only adapter that is really needed to provide support for retrieving feeds is an inbound channel adapter
+ which allows you to subscribe to a particular URL. Below is the configuration for such adapter:
+
+
+
+]]>
+
+ In the above configuration we are subscribing to a URL identified by url attribute.
+
+
+ As news items are retrieved they will be converted to a Message and sent to a channel identified by channel attribute.
+ The payload of such message will be com.sun.syndication.feed.synd.SyndEntry which encapsulates
+ various data (i.e., content, dates, authors etc.) about a news item.
+
+
+ You can also see that Inbound Feed Channel Adapter is a Polling consumer which means you have to
+ provide a poller configuration. However, one important thing you must understand with regard to Feed sinc its inner-workings
+ are slightly different then any other poling consumer. When Inbound Feed adapter is started it does the first poll and
+ receives com.sun.syndication.feed.synd.SyndEntryyFeed which is an object that contains multiple
+ SyndEntry objects. Each entry is stored in the local entry queue and is released based on
+ the value in the max-messages-per-poll attribute where each Message will contain a single entry.
+ If during retrieval of the entries from the entry queue the queue had become empty the adapter will attempt to update
+ the Feed populating the queue with more entries (SyndEntry) if available, otherwise the next attempt to poll for a feed will
+ be determined by the trigger of the poller (e.g., every 10 seconds in the above configuration).
+
+
+
+ Duplicate Entries
+
+
+ Polling for a Feed might result in the entries that have already been processed ("I already read that news item, why are you showing it to me again?").
+ Spring Integration provides a convenient mechanism to eliminate the need to worry about duplicate entries.
+ Each feed entry will have publish date field. Every time the new Message is generated and sent,
+ Spring Integration will store the value of the publish date in the instance of the
+ org.springframework.integration.store.MetadataStore which is a strategy interface designed to store various
+ types of meta-data (e.g., publish date of the last feed entry that has been processed) to help components such as Feed to deal with
+ duplicates.
+
+
+ The default rule for locating this meta-data store is as follows; Spring Integration will look for a bean of type
+ org.springframework.integration.store.MetadataStore in the ApplicationContext. If one found then it will be used,
+ otherwise it will create a new instance of SimpleMetadataStore which is a simple in-memory implementation that
+ will only persist meta-data within the life-cycle of the application context. This means that upon restart you may end up with
+ duplicate entries. If you need to persist meta-data between Application Context restarts, you may use
+ PropertiesPersistingMetadataStore which is a property file based persister or provide your own
+ implementation of the MetedataStore interface (e.g.,JdbcMetadatStore) and configure it as bean in the Application Context.
+
+ ]]>
+
+
diff --git a/spring-integration-feed/src/main/java/org/springframework/integration/feed/inbound/FeedEntryMessageSource.java b/spring-integration-feed/src/main/java/org/springframework/integration/feed/inbound/FeedEntryMessageSource.java
index 44eb19cbed..7f6c94cf96 100644
--- a/spring-integration-feed/src/main/java/org/springframework/integration/feed/inbound/FeedEntryMessageSource.java
+++ b/spring-integration-feed/src/main/java/org/springframework/integration/feed/inbound/FeedEntryMessageSource.java
@@ -60,8 +60,6 @@ public class FeedEntryMessageSource extends IntegrationObjectSupport implements
private final FeedFetcher feedFetcher;
- private final Queue feeds = new ConcurrentLinkedQueue();
-
private final Queue entries = new ConcurrentLinkedQueue();
private volatile String metadataKey;
@@ -253,12 +251,6 @@ public class FeedEntryMessageSource extends IntegrationObjectSupport implements
logger.debug("\tEVENT: Feed Polled. URL = " + event.getUrlString());
}
}
- else if (FetcherEvent.EVENT_TYPE_FEED_RETRIEVED.equals(eventType)) {
- if (logger.isDebugEnabled()) {
- logger.debug("\tEVENT: Feed Retrieved. URL = " + event.getUrlString());
- }
- feeds.add(event.getFeed());
- }
else if (FetcherEvent.EVENT_TYPE_FEED_UNCHANGED.equals(eventType)) {
if (logger.isDebugEnabled()) {
logger.debug("\tEVENT: Feed Unchanged. URL = " + event.getUrlString());