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 > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
