[infinispan-dev] org.infinispan.notifications.cachelistener.filter vs org.infinispan.filter
Emmanuel Bernard
emmanuel at hibernate.org
Tue Mar 3 10:32:11 EST 2015
Should it be morphed into a FAQ?
> On 03 Mar 2015, at 16:23, Galder Zamarreño <galder at 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 at gmail.com> wrote:
>>
>> On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarreño <galder at 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 at redhat.com
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> --
> Galder Zamarreño
> galder at redhat.com
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
More information about the infinispan-dev
mailing list