[infinispan-dev] Proposed ISPN 7 compilation incompatibilities with ISPN 6

[Pedro Ruivo]

On 03/13/2014 12:35 PM, William Burns wrote:
> On Thu, Mar 13, 2014 at 8:31 AM, Pedro Ruivo <pedro at infinispan.org> wrote:
>> Hi,
>>
>> #1 and #2 are ok to me but, IMO, the filter package should be in commons
>> module
>
> Sorry I forgot to detail why I said core.  I originally planned for
> commons package as well, however the KeyValueFilter class needs the
> Metadata class, which doesn't live in the commons package.  I didn't
> want to separate the 2 filter classes.  And unfortunately the Metadata
> class relies on other classes in core, so that isn't easy to move over
> either, but doable :(  WDYT?

can you explain why the metadata is needed? I assumed that the key and 
the value were the only objects needed.

>
>>
>> Cheers,
>> Pedro
>>
>> On 03/13/2014 12:07 PM, William Burns wrote:
>>> Recently while working on some ISPN 7 features, there were some public
>>> API inconsistencies.  I wanted to bring these up just in case if
>>> someone had concerns.
>>>
>>> The first few are pretty trivial, but can cause compilation errors
>>> between versions if user code implements these interfaces and defines
>>> types.
>>>
>>> 1. The CacheWriter interface currently defines a delete(K key) method.
>>>    To be more inline with JCache and java.util.collections interfaces I
>>> was hoping to change this to be delete(Object key) instead.
>>> 2. The CacheLoader interface currently defines load(K key) and
>>> contains(K key) methods.  Similar to above I was hoping to change the
>>> K type to be Object to be more inline with JCache and
>>> java.util.collections interfaces.
>>>
>>> This last one is a bit more major, but currently we have 2 classes
>>> that are named KeyFilter.  One that resides in the
>>> org.infinispan.notifications package and another that resides in the
>>> org.infinispan.persistence.spi.AdvancedCacheLoader interface.
>>>
>>> 3. My plan is instead to consolidate these classes into 1 into a new
>>> core org.infinispan.filter package.  I would also move the new
>>> KeyValueFilter class that was added for cluster listeners into this
>>> package and their accompanying implementations.
>>>
>>> The first 2 is currently implemented as changes in
>>> https://github.com/infinispan/infinispan/pull/2423.  The latter I was
>>> going to add into changes for
>>> https://issues.jboss.org/browse/ISPN-4068.
>>>
>>> Let me know what you guys think.
>>>
>>>    - Will
>>> _______________________________________________
>>> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>