[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