[infinispan-dev] org.infinispan.notifications.cachelistener.filter vs org.infinispan.filter

[Galder Zamarreño]

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