[jboss-jira] [JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests

[Brian Stansberry (JIRA)]

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

Brian Stansberry commented on WFCORE-2217:
------------------------------------------

"I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives."

Removing the ability to do this fairly easily is the big concern. A big thing the subsystem tests do is set everything and then confirm it goes through the marshal/re-parse processing correctly.

I think it's valid to ask test authors to configure something to turn on that leniency but we should think about how to do that nicely, as configuring subsystem tests is already quite painful.

> ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2217
>                 URL: https://issues.jboss.org/browse/WFCORE-2217
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Domain Management
>    Affects Versions: 3.0.0.Alpha16
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>             Fix For: 3.0.0.Alpha20, 4.0.0.Beta1
>
>
> During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java#L495 which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java#L523 does not get called.
> The fix is quite simple:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
>              }
>  
>              resultAction = postExtContext.executeOperation();
> +        }
>  
> -            if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> -                //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> -                Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                Resource root = managementModel.get().getRootResource();
> -                addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> -                final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> -                        EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> -                        contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> -                                bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> -                                extraValidationStepHandler, partialModel, securityIdentitySupplier);
> -                validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> -                resultAction = validateContext.executeOperation();
> -            }
> +        if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> +            //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> +            Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            Resource root = managementModel.get().getRootResource();
> +            addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> +            final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> +                    EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> +                    contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> +                    bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> +                    extraValidationStepHandler, partialModel, securityIdentitySupplier);
> +            validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> +            resultAction = validateContext.executeOperation();
>          }
>  
>          return  resultAction == OperationContext.ResultAction.KEEP;
> {code}
> but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full.
> I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives.
> For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is:
> {code}
> diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> index 4a6cc7c..d8e1911 100644
> --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java
> @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController {
>              }
>  
>              resultAction = postExtContext.executeOperation();
> +        }
>  
> -            if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) {
> -                //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> -                Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> -                Resource root = managementModel.get().getRootResource();
> -                addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> -
> -                final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> -                        EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> -                        contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> -                                bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> -                                extraValidationStepHandler, partialModel, securityIdentitySupplier);
> -                validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> -                resultAction = validateContext.executeOperation();
> -            }
> +        if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) {
> +            //Get the modified resources from the initial operations and add to the resources to be validated by the post operations
> +            Set<PathAddress> validateAddresses = new HashSet<PathAddress>();
> +            Resource root = managementModel.get().getRootResource();
> +            addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses);
> +
> +            final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION,
> +                    EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(),
> +                    contextFlags, handler, null, managementModel.get(), control, processState, auditLogger,
> +                    bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false,
> +                    extraValidationStepHandler, partialModel, securityIdentitySupplier);
> +            validateContext.addModifiedResourcesForModelValidation(validateAddresses);
> +            resultAction = validateContext.executeOperation();
>          }
>  
>          return  resultAction == OperationContext.ResultAction.KEEP;
> {code}
> So although the fix is simple, the fallout of this is quite big. 



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