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

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: Bug Components: Domain Management Affects Versions: 3.0.0.Alpha16 Reporter: Kabir Khan Fix For: 4.0.0.Alpha1 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... which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... 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.