[jboss-jira] [JBoss JIRA] (WFCORE-2674) An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative

[Brian Stansberry (JIRA)]

    [ https://issues.jboss.org/browse/WFCORE-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13393770#comment-13393770 ] 

Brian Stansberry commented on WFCORE-2674:
------------------------------------------

Jeff noted that:

"the case of the deployment 'add' operation 'archive' property is interesting. The 'requires' contains path/hash/empty that are alternatives."

So a question I have is why this isn't failing some CI test with https://github.com/wildfly/wildfly-core/pull/2219, which should be bringing validation to the elements in the 'content' list attribute in deployment resources.

> An attribute that another attribute 'requires' should be allowed to be undefined if another attribute in the same set of 'requires' is an alternative
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-2674
>                 URL: https://issues.jboss.org/browse/WFCORE-2674
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> Right now ValidateModelStepHandler checks whether all attributes a defined attribute lists in 'requires' are themselves defined. It ignore the presence of alternatives settings. However in discussion with [~jfdenise] we've concluded that allowing undefined do to any 'alternatives' isn't right either. Rather, for a 'requires' to be superceded by an 'alternatives', only alternatives that are themselves part of the same set of 'requires' are relevant.
> Imagine three scenarios:
> I.
> 1) A requires B, C 
> 2) B and C are alternatives to each other 
> User configures A and B is ok. Or, user configures A and C is ok. Configuring A, B, C is not ok. 
> II.
> 1) A requires B, C 
> 2) B and C are alternatives to each other 
> 3) B and D are also alternatives
> User configures A and D and therefore must configure C, but not B. Configuring C satisfies the "requires" B.
> III.
> 1) A requires B, C 
> 2) B and C are NOT alternatives to each other 
> 3) B and D are alternatives
> User configures A therefore cannot configure D, must configure B and C. Configuring D does not satisfy the "requires" B.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)