[infinispan-dev] Feedback and requests on clustered and remote listeners
galder at redhat.com
Wed Sep 24 02:16:04 EDT 2014
On 23 Sep 2014, at 19:02, William Burns <mudokonman at gmail.com> wrote:
> On Tue, Sep 23, 2014 at 12:20 PM, Galder Zamarreño <galder at redhat.com> wrote:
>> On 23 Sep 2014, at 14:53, Mircea Markus <mmarkus at redhat.com> wrote:
>>> On Sep 23, 2014, at 15:18, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>>> I am not sold on this as it seems pretty trivial to decipher which
>>>>> operation is which and the information would be present on the
>>>>> javadocs as well.
>>>> I very strongly disagree. Cf the other thread with Radim 's comment on topology error.
>>>> And think about *future* evolutions. The enum would make that much safer. In the bin enum world you would have to introduce a new YetAnotherKeyValueFilter interface :)
>>> Nicer than an enum would be an explicit method, e.g. handlePut/handleDelete/handleCreate/handleUpdate, as these would also receive the appropriate param list.
>> ^ Hmmmmm, not sure I like that. If you look at the remote event blog posts, you’ll see that I use create/modify/remove annotations and then the parameter to the callback varies depending on whether you had converter applied to it or not. IOW, without a converter, a created event parameter is a ClientCacheEntryCreatedEvent, whereas with a converter, the parameter is a ClientCacheEntryCustomEvent. Two different types of events for the same event type. If you did it with explicit methods, you’d have to duplicate them for custom events.
> This is for embedded and is done in the filter and converter (not in
> the listener). Unless I am missing something this shouldn't directly
> affect the client methods.
>>> Of course this means moving away from the KeyValueFilter to an UpdateFilter (good name, Radim) used only for cluster listeners.
>> I don’t like the name actually. I associate update with modifications, and in similar vein, inserts with creation and delete with removals.
> What would you suggest? A few things I thought of quickly:
> CacheOperationFilter, CacheEventFilter, CacheWriteFilter - the only
> reason I preface Cache is because we have CacheManager events as well.
>>> Will, what would be the overall impact on the API as right now the KeyValueFilter is reused between several components, like the cluster iterator.
>>> Mircea Markus
>>> Infinispan lead (www.infinispan.org)
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>> Galder Zamarreño
>> galder at redhat.com
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
galder at redhat.com
More information about the infinispan-dev