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
