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

[Kabir Khan (JIRA)]

Kabir Khan created WFCORE-2217:
----------------------------------

             Summary: 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)