On 26 Feb 2015, at 15:12, William Burns <mudokonman(a)gmail.com&gt; wrote: On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarreño <galder(a)redhat.com&gt; 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

On 3 Mar 2015, at 16:32, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: Should it be morphed into a FAQ? > On 03 Mar 2015, at 16:23, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > > 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&gt; wrote: >> >> On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarreño <galder(a)redhat.com&gt; 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 > > > > > > _______________________________________________ > 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