Re: [infinispan-dev] Feedback and requests on clustered and remote listeners

Sorry for the long delay. I looked at your PR early last week and it looked good to me. I think it might be slighly more efficient to offer a single contract that do both the filtering and the conversion (esp when one consider reading the value in raw protobuf and do the parsing once). But your approach solves the old / new value feature.

Emmanuel On 30 Sep 2014, at 18:13, William Burns <mudokonman(a)gmail.com&gt; wrote: > I have put it on a branch on github and you can try it out and let me > know what you think. > > I still have a few things I may want to change though: > > 1. I don't like how pre events are yet as they don't give you the > previous value and new value as post events do > 2. The enum to tell the type has become a bit more complicated and I > think I am going to change it to a class > 3. I also have some internal changes that should require less memory > allocations I wanted to clean up. > > https://github.com/wburns/infinispan/tree/ISPN-4753 > > Thanks, > > - Will > > On Fri, Sep 26, 2014 at 4:06 AM, Emmanuel Bernard > <emmanuel(a)hibernate.org&gt; wrote: >> You lost me at actually ;) but if you have some code or even a gist showing how a user would use and interact with these changes, I can give you some feedback on the use cases I had in mind and if they fit. >> >> >>> On 25 sept. 2014, at 15:20, William Burns <mudokonman(a)gmail.com&gt; wrote: >>> >>> Actually while working and thinking on this it seems it may be easiest >>> to exclude the usage of KeyValueFilter in the listener pieces >>> completely and instead leave the annotation as it is now. Instead the >>> provided CacheEventFilter would be wrapped by a KeyValueFilter >>> implement that just called the new method as if it was a create event >>> for each value while iterating on them. I am thinking this is the >>> cleanest. Do you guys have any opinions? It would also keep intact a >>> lot of existing code and APIs. >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev