[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on ISPN-4919 at 12/2/14 11:29 AM: -------------------------------------------------------------- [~NadirX] I'm not arguing against the concept, just the usability/implementation. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for templates vs extending caches, where the resource attribute definitions for extending caches are completely nullable. In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration. It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation? was (Author: pferraro): [~NadirX] I'm not arguing against the concept, just the usability/implementation. It's not just the schema that implies different behavior, but the Resources themselves. The cache resource and its children don't have nullable attributes. Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation. So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the resource attribute definitions for extending caches are completely nullable. In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache. You guys changed this in 5.x-7.0, where Configuration objects are now completely defined. new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration. Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration. It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior. Is that a fair summation? -- This message was sent by Atlassian JIRA (v6.3.8#6338)