In terms of breaking compatibility, here is the impact: 1. XML cfg No impact here since XML cfg is changing anyway. Mircea's translation script can be modeified to take care of this. 2. Programmatic cfg * Minor impact, EvictionConfig.set/getDefaultXXX will go away. * XmlConfigurationParser would have to create a normal EvictionRegionConfig for the default element and add it to the EvictionConfig using setDefaultEvictionRegionConfig(). * All other EvictionRegionConfigs will inherit values from EvictionConfig.getDefaultEvictionRegionConfig() for unset properties. This could be done by EvictionConfig when addEvictionRegionConfig() is called. * XXXPolicyConfig will have to be replaced with XXXAlgorithmConfig. * EvictionPolicyConfig interface replaced with EvictionAlgorithmConfig * EvictionRegionConfig references to EvictionPolicyConfig will be changed to EvictionAlgorithmConfig * EvictionRegionConfig will also take in a EvictionPolicy class name. 3. Using Region * getEvictionPolicy(), getEvictionPolicyConfig(), getEvictionRegionConfig(), and all other eviction related methods will disappear, save for the 3 methods detailed above. 4. Implementing custom eviction algorithms. * If extending an existing EvictionAlgorithm or the BaseEvictionAlgorithm, this should be simple and not require any changes. * Any new algorithm implemented will have to provide an EvictionAlgorithmConfig instead of an EvictionPolicyConfig View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169650#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...