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 <[email protected]> wrote: > > On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarreño <[email protected]> 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 >> [email protected] >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
