Should it be morphed into a FAQ? > On 03 Mar 2015, at 16:23, Galder Zamarreño <gal...@redhat.com> 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 <mudokon...@gmail.com> wrote: >> >> On Thu, Feb 26, 2015 at 3:57 AM, Galder Zamarreño <gal...@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 >>> gal...@redhat.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Galder Zamarreño > gal...@redhat.com > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
