On 24 Sep 2014, at 09:10, Radim Vansa <rva...@redhat.com> wrote: > On 09/24/2014 08:16 AM, Galder Zamarreño wrote: >> On 23 Sep 2014, at 19:02, William Burns <mudokon...@gmail.com> wrote: >> >>> On Tue, Sep 23, 2014 at 12:20 PM, Galder Zamarreño <gal...@redhat.com> >>> wrote: >>>> On 23 Sep 2014, at 14:53, Mircea Markus <mmar...@redhat.com> wrote: >>>> >>>>> On Sep 23, 2014, at 15:18, Emmanuel Bernard <emman...@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. >> Ah ok. >> >>>>> 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. >> Maybe CacheEventFilter... > > Does expiration trigger clustered listeners?
Expiration events are not there yet: https://issues.jboss.org/browse/ISPN-694 It’s assigned to me but I’ve had my hands full with HR 2.0 related stuff... > 'Event' sounds quite > generic, I would expect the EventFilter to be able to handle > expirations, invalidations, evictions etc., maybe even reads as well > (whether through separate methods or enums). You can indeed listen for cache entry visited events, at least in local listeners. > > ModificationFilter could be better (in TX I think we use term > 'modifications' for all CUD ops), but we have already used > CacheEntryModified for 'update'. > > >> >>>>> Will, what would be the overall impact on the API as right now the >>>>> KeyValueFilter is reused between several components, like the cluster >>>>> iterator. >>>>> >>>>> Cheers, >>>>> -- >>>>> Mircea Markus >>>>> Infinispan lead (www.infinispan.org) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> infinispan-dev@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> -- >>>> Galder Zamarreño >>>> gal...@redhat.com >>>> twitter.com/galderz >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Galder Zamarreño >> gal...@redhat.com >> twitter.com/galderz >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rva...@redhat.com> > JBoss DataGrid QA > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
