camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen" <claus.ib...@gmail.com>
Subject Re: Deprecation of file consumer timestamp
Date Mon, 01 Dec 2008 11:42:05 GMT
On Mon, Dec 1, 2008 at 11:58 AM, James Strachan
<james.strachan@gmail.com> wrote:
> 2008/12/1 Claus Ibsen <claus.ibsen@gmail.com>:
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>>
>> On Mon, Dec 1, 2008 at 11:44 AM, James Strachan
>> <james.strachan@gmail.com> wrote:
>>> 2008/11/29 Claus Ibsen <claus.ibsen@gmail.com>:
>>>> Hi
>>>>
>>>> I am reworking the file component as the code needs to be polished to
>>>> be ready for new feature requests by end users.
>>>>
>>>> Having my fingers on the keyboard and reworking the code I do think we
>>>> should consider letting the idempotent consumer EIP pattern having a
>>>> first class interface for consumers to implement to support idempotent
>>>> right out-of-the-box. This is convenient for both the file and ftp
>>>> consumers to avoid re-consuming already processed files.
>>>>
>>>> Then we could allow very easy URI configuration for the file consumer
>>>> to enable the idempotent
>>>> from("file://inbox?idempotent=true").to("bean:processOrder");
>>>
>>> Great idea!
>>>
>>>> So I am proposing to either
>>>> a) add a new interface in org.apache.camel to cater for this
>>>> b) move the existing interface MessageIdRepository to org.apache.camel
>>>> c) option b but renaming the interface to a better name, IdempotentRepository
>>>>
>>>> Using the existing MessageIdRepository allows us to leverage existing
>>>> implementations such as the JpaMessageIdRepository so we can support a
>>>> persistent solution right out-of-the-box.
>>>
>>> Sounds good - how about IdempotentRepository being in the camel.spi package?
>> Yeah that is a great home for it ;)
>>
>> Maybe we should add a peek method to see if an id has been processed before
>>
>> contains will add it if missing, so we might need a "read-only peek method"
>>  boolean contains(String key);
>>
>>  boolean peek(String key);
>>
>> Anyone got a better name for peek?
>
> How about following the Set naming convention?
>
> boolean add(element) // Returns true if this set did not already
> contain the specified element.
>
> boolean contains(element) // for peek
+1, however existing implementations change from contains to add to
keep current behavior. We should just state this in the release notes.
End users with custom implementations must change their code anyway as
we rename and move the interface.



>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://fusesource.com/
>

Mime
View raw message