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

[William Burns]

On Wed, Oct 15, 2014 at 7:54 AM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:
> 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.

I agree, that is something that will still need to be added to the
listeners.  Most likely it will be implemented in a similar fashion as
KeyValueFilterConverter was.  I have created [1] to track it.

[1] https://issues.jboss.org/browse/ISPN-4850

>
> Emmanuel
>
> On 30 Sep 2014, at 18:13, William Burns <mudokonman at gmail.com> 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 at hibernate.org> 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 at gmail.com> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev