[infinispan-dev] org.infinispan.notifications.cachelistener.filter vs org.infinispan.filter

[Galder Zamarreño]

Yeah, should do: https://github.com/infinispan/infinispan/pull/3323 :)

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


--
Galder Zamarreño
galder at redhat.com