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