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

[William Burns]

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