On 3 Mar 2015, at 16:32, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
Should it be morphed into a FAQ?
> On 03 Mar 2015, at 16:23, Galder Zamarreño <galder(a)redhat.com> wrote:
>
> Hmm, ok. It's true that down the line the remote events might morph into more
specialised DSL-based remote event filter/conversion.
>
> I just wished the naming would have been a bit more representative.
>
> Ideally, the filter/converter classes used for remote events should have lived in a
remote jar and be named accordingly, but they had to live in core, which has made it a
little akward.
>
> Some users might want to check old value even for cluster listeners, in that case
it's a little akward the way it's now. I guess time will tell. I also wonder
whether Java 8's default methods might enable more selective implementation, but using
it to encompass both types of filters might be a misused. Just some thoughts.
>
> Will, thanks for the clear response :)
>
>> On 26 Feb 2015, at 15:12, William Burns <mudokonman(a)gmail.com> wrote:
>>
>> On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarreño <galder(a)redhat.com>
wrote:
>>> Hey Will,
>>>
>>> I wanted to ask you about the classes in org.infinispan.filter package.
>>>
>>> I thought we agreed to get rid of these duplicate classes before
7.0.0.Final:
>>> - org.infinispan.filter.Converter
>>> - org.infinispan.filter.KeyValueFilter
>>> - ... and related classes
>>>
>>> The reason being that we pretty much had the same classes in
org.infinispan.notifications.cachelistener.filter package.
>>
>> I agree they are very similar.
>>
>>>
>>> Both set of classes were added in 7.0, so there's no reason why we should
have left both sets around :|
>>
>> Each one fulfills a different purpose. Originally only the 1 set of
>> classes was used, but event filters evolved to have new requirements
>> (oldValue, oldMetadata, retry, event type) that don't make sense for
>> normal filtering. The regular KeyValueFilter, KeyFilter, Converter
>> classes are still used when filtering existing entries (CacheLoader,
>> EntryIterator). Also the simpler filter & converter will be able to
>> be used as stepping stones for Streams when we move to Java 8
>> (although a tweak to the interface(s) will probably be required).
>>
>>>
>>> These latter classes provide more information, but it can confuse users to
decide which filters/converters to use where and how.
>>
>> The CacheEventFilter/CacheEventFilterConverter are only used when
>> using events. The other simpler filters are used in all other cases..
>>
>>>
>>> Am I missing something here?
>>
>> The classes we talked about removing were the *Factory classes for the
>> various filters. We can discuss converging the ones you mentioned
>> here, but IMO the provided functionality has diverged quite a bit,
>> which would make having a consistent API very ugly for one or both of
>> the use cases.
>>
>>>
>>> We would not be able to remove anything now, but we should deprecate what
should not be used.
>>>
>>> From a remote even perspective, only the
org.infinispan.notifications.cachelistener.filter ones are relevant.
>>
>> I would say from a remote event perspective you are correct. However
>> once we add entry iteration for remote, we would want to use the more
>> simplified interfaces.
>>
>>>
>>> Cheers,
>>> --
>>> Galder Zamarreño
>>> galder(a)redhat.com
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> --
> Galder Zamarreño
> galder(a)redhat.com
>
>
>
>
>
> _______________________________________________
> 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