[wildfly-dev] Fixing handling of 'required' attributes with 'alternatives'

[Brian Stansberry]

> On Sep 12, 2016, at 7:44 AM, Heiko W.Rupp <hrupp at redhat.com> wrote:
> 
> On 6 Sep 2016, at 15:10, Brian Stansberry wrote:
> 
>> It’s not an uncommon thing to have a management attribute A that is required; i.e. must be set, but also has an alternative attribute B, where setting B satisfies the requirement for A, making an undefined value for A legal.
> 
> Would this also include cases where e.g. a logger has an
> attribute 'mode' which could be one of file, console, rsyslog
> and then dependent attributes that are only usable with
> one of the modes. Something like filename for 'file',
> none for 'console' and 'remote-socket-binding' for 'rsyslog' ?
> Both 'filename' and 'remote-socket-binding' would be
> required only for their mode (and even forbidden otherwise).

No, that kind of thing is not covered by this work. We have ‘requires’ metadata for an attribute that names other attributes that must be set if the given attribute is set, but that’s just a relationship based on defined vs undefined, not on any particular defined value. There would need to be some sort of new metadata added to cover what you describe. Perhaps something like

“requires-if => [
    {
       “value” => true,
       “attributes” => [“another”, “athird”]
    },
    {
       “value” => false,
       “attributes” => [“afourth”, “afifth”]
    },
  ]

Note that for something like that we couldn’t support it for attributes that allow expressions, as the validation of the constraint would need to happen before we’re able to accurately resolve expressions. But for enum attributes like your example I don’t think that would be an issue. I don’t imagine using an expression to control an enum would be a typical thing.

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat