[JBoss JIRA] (WFCORE-2591) deployment add/add-content alternatives and required issues
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2591?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2591:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Brian Stansberry)
[~ehugonnet] I think you are already looking at this.
> deployment add/add-content alternatives and required issues
> -----------------------------------------------------------
>
> Key: WFCORE-2591
> URL: https://issues.jboss.org/browse/WFCORE-2591
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Jean-Francois Denise
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> add operation
> - content should be required.
> - alternatives hash/bytes/url/path/input-stream-index/empty should be required.
> add-content operation
> - content should be required.
> - alternatives input-stream-index/hash/bytes/url should be required.
> - alternatives empty/relative-to/path should not be present in alternatives list.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2605) Upgrade DMR to 1.4.0.Final
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2605:
----------------------------------------
Summary: Upgrade DMR to 1.4.0.Final
Key: WFCORE-2605
URL: https://issues.jboss.org/browse/WFCORE-2605
Project: WildFly Core
Issue Type: Component Upgrade
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Beta12
Just a pom change to the currently used 1.4.0.Beta2 to promote it to final.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2604) Upgrade DMR to 1.4.0.Final
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2604:
----------------------------------------
Summary: Upgrade DMR to 1.4.0.Final
Key: WFCORE-2604
URL: https://issues.jboss.org/browse/WFCORE-2604
Project: WildFly Core
Issue Type: Component Upgrade
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Beta12
Just a pom change to the currently used 1.4.0.Beta2 to promote it to final.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2217:
-------------------------------------
Issue Type: Bug (was: Component Upgrade)
> 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
> Assignee: Brian Stansberry
> 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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (ELY-1029) Support clients that provide an optional CallbackHandler
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1029?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1029:
----------------------------------
Fix Version/s: 1.1.0.Beta35
(was: 1.1.0.Beta34)
> Support clients that provide an optional CallbackHandler
> --------------------------------------------------------
>
> Key: ELY-1029
> URL: https://issues.jboss.org/browse/ELY-1029
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: Authentication Client
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.1.0.Beta35
>
>
> Clients such as the WildFly CLI provide a CallbackHandler implementation in case it is needed and not as a sign that it must be used, i.e. the desired outcome is that if the information required can be obtained from the configuration then authentication proceeds without interaction with the end user.
> Neither the CLI or the end user should be required to be fully aware of the underlying security configuration.
> This is similar to web browser HTTP authentication where there is only an interaction with the user if actually required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month