[infinispan-issues] [JBoss JIRA] (ISPN-11714) Auto-enable XML config elements when the element is present but its 'enabled' attribute is omitted

[Nistor Adrian (Jira)]

     [ https://issues.redhat.com/browse/ISPN-11714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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)