Hi,
#1 and #2 are ok to me but, IMO, the filter package should be in commons
module
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev