[
https://issues.redhat.com/browse/ISPN-11714?page=com.atlassian.jira.plugi...
]
Nistor Adrian updated ISPN-11714:
---------------------------------
Description:
This is a generic issue that applies to multiple config areas: stores, xsite, security,
jmx, indexing, partition handling.... We do have an 'enabled' attribute in other
areas also, like state transfer where it is enabled by default, but we are not concerned
with those. This issue only touches the cases where the XSD default value is false
requiring the user to explicitly put enabled="true" in the config element.
Rather than doing that we should simplify things , for usability, and if the element is
present and the attribute is omitted we should auto-enable it.
This touches strictly xml config. Programmatic config still requires an explicit enable
call.
The xml parser will only have this behaviour for schemas starting with 11.
TBD: 1. what do we do for JSON based config or other possible text formats?
2. What do we do about programmatic auto-enable, like in
AbstractGlobalConfigurationBuilder.globalState() ?
NOTE: The indexing case is handled separately as it stands better chance to be resolved by
next major release, here:
https://issues.redhat.com/browse/ISPN-11712
was:
This is a generic issue that applies to multiple config areas: stores, xsite, security,
jmx, indexing, partition handling.... We do have an 'enabled' attribute in other
areas also, like state transfer where it is enabled by default, but we are not concerned
with those. This issue only touches the cases where the XSD default value is false
requiring the user to explicitly put enabled="true" in the config element.
Rather than doing that we should simplify things , for usability, and if the element is
present and the attribute is omitted we should auto-enable it.
This touches strictly xml config. Programmatic config still requires and explicit enable
call.
The xml parser will only have this behaviour for schemas starting with 11.
TBD: 1. what do we do for JSON based config or other possible text formats?
2. What do we do about programmatic auto-enable, like in
AbstractGlobalConfigurationBuilder.globalState() ?
NOTE: The indexing case is handled separately as it stands better chance to be resolved by
next major release, here:
https://issues.redhat.com/browse/ISPN-11712
Auto-enable XML config elements when the element is present but its
'enabled' attribute is omitted
--------------------------------------------------------------------------------------------------
Key: ISPN-11714
URL:
https://issues.redhat.com/browse/ISPN-11714
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 11.0.0.Alpha1
Reporter: Nistor Adrian
Assignee: Nistor Adrian
Priority: Major
This is a generic issue that applies to multiple config areas: stores, xsite, security,
jmx, indexing, partition handling.... We do have an 'enabled' attribute in other
areas also, like state transfer where it is enabled by default, but we are not concerned
with those. This issue only touches the cases where the XSD default value is false
requiring the user to explicitly put enabled="true" in the config element.
Rather than doing that we should simplify things , for usability, and if the element is
present and the attribute is omitted we should auto-enable it.
This touches strictly xml config. Programmatic config still requires an explicit enable
call.
The xml parser will only have this behaviour for schemas starting with 11.
TBD: 1. what do we do for JSON based config or other possible text formats?
2. What do we do about programmatic auto-enable, like in
AbstractGlobalConfigurationBuilder.globalState() ?
NOTE: The indexing case is handled separately as it stands better chance to be resolved
by next major release, here:
https://issues.redhat.com/browse/ISPN-11712
--
This message was sent by Atlassian Jira
(v7.13.8#713008)