[JBoss JIRA] (WFCORE-2245) credential-reference capability-reference constraint
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2245:
-------------------------------------
Fix Version/s: 3.0.0.Beta1
(was: 3.0.0.Alpha25)
> credential-reference capability-reference constraint
> ----------------------------------------------------
>
> Key: WFCORE-2245
> URL: https://issues.jboss.org/browse/WFCORE-2245
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Claudio Miranda
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Beta1
>
>
> There attribute credential-reference is defined in many subsystems as below. Looks like the capability-reference constraint should be set in the "store" field of the value-type, therefore I request a review on this capability-constraint placement.
> {code}
> "credential-reference" => {
> "type" => OBJECT,
> "description" => "Credential (from Credential Store) to authenticate on data source",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "capability-reference" => "org.wildfly.security.credential-store",
> "access-constraints" => {"sensitive" => {
> "credential" => {"type" => "core"},
> "data-source-security" => {"type" => "datasources"}
> }},
> "value-type" => {
> "store" => {
> "type" => STRING,
> "description" => "The name of the credential store holding the alias to credential",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "alias" => {
> "type" => STRING,
> "description" => "The alias which denotes stored secret or credential in the store",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "type" => {
> "type" => STRING,
> "description" => "The type of credential this reference is denoting",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "clear-text" => {
> "type" => STRING,
> "description" => "Secret specified using clear text (check credential store way of supplying credential/secrets to services)",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> },
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "all-services"
> },
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[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:
-------------------------------------
Fix Version/s: 3.0.0.Beta1
(was: 3.0.0.Alpha25)
> 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.Beta1, 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... 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)
9 years, 2 months
[JBoss JIRA] (WFLY-8087) Statistics Resources are being created without a corresponding ManagementResourceRegistration
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8087:
--------------------------------------
Summary: Statistics Resources are being created without a corresponding ManagementResourceRegistration
Key: WFLY-8087
URL: https://issues.jboss.org/browse/WFLY-8087
Project: WildFly
Issue Type: Bug
Components: JCA, JMS
Reporter: Brian Stansberry
Assignee: Brian Stansberry
While working on WFCORE-2286 I discovered that there are resources in the tree, at least on the DC, for which there is no corresponding MRR. I believe [~pferraro] in some recent work he's done has stumbled on a similar thing.
I found there were no MRRs for
/profile=*/subsystem=messaging-activemq/server=*/pooled-connection-factory=*/statistics=pool
/profile=*/subsystem=datasources/data-source=*/statistics=jdbc
/profile=*/subsystem=datasources/data-source=*/statistics=pool
I expect the latter two would be repeated for xa-data-source=*
Probably the lack of MRR is correct and the problem is the existence of the resource.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly handles duplicate module names
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1717:
-------------------------------------
Fix Version/s: 3.0.0.Alpha25
(was: 3.0.0.CR1)
> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
> Key: WFCORE-1717
> URL: https://issues.jboss.org/browse/WFCORE-1717
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Toby Crawley
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha25
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
> IllegalStateException that occurs when trying to generate the
> XMLStreamException
> (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-1717) ExtensionXml incorrectly handles duplicate module names
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1717?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1717:
----------------------------------------
Assignee: Brian Stansberry
> ExtensionXml incorrectly handles duplicate module names
> -------------------------------------------------------
>
> Key: WFCORE-1717
> URL: https://issues.jboss.org/browse/WFCORE-1717
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.2.0.Final, 3.0.0.Alpha5
> Reporter: Toby Crawley
> Assignee: Brian Stansberry
> Fix For: 3.0.0.CR1
>
>
> Toby Crawley reports:
> - adding a duplicate extension under server > extensions causes an
> IllegalStateException that occurs when trying to generate the
> XMLStreamException
> (https://gist.github.com/tobias/59d155afe0c88e268b83cb75734353eb)
> The problem happens because before the parser calls the invalidAttributeValue method to throw an exception, it has already consumed the element, preventing invalidAttributeValue working properly.
> This should really be a custom exception that more clearly explains the problem, which is that the 'module' attribute value must be unique across the extension elements.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8086) WebMigrateOperation makes invalid assumption about web subsystem "describe" output ordering
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8086:
--------------------------------------
Summary: WebMigrateOperation makes invalid assumption about web subsystem "describe" output ordering
Key: WFLY-8086
URL: https://issues.jboss.org/browse/WFLY-8086
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The WebMigrateOperation iterates over the operations produced by running 'describe' against the web subsystem, checking different operations and converting them. When it gets to a /subsystem=web/host=* op it processes that in its migrateVirtualHost method. But that method as part of its work checks all the other *already migrated* ops looking for path filters and the access log valve. If found it adds additional child resource add ops.
This is flawed because it assumes any add op for an access log valve or path filter will have already been created when migrateVirtualHost is run. That's not a valid assumption as there is nothing in the contract of the describe operation that guarantees such an order in its output. Work on WFCORE-2286 has revealed this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8085) ExpressionSupportSmokeTestCase doesn't properly handle attributes with undefined required attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8085?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8085:
----------------------------------------
Using a composite alone isn't enough here. We also need to deal with other reasons why the required attribute is invalid; e.g. it's a capability reference etc.
If the undefined required attribute has a default value we could set it to that. If it doesn't, we can't set it regardless. But a required attribute would be undefined but with a default value is either 1) illegal for reasons I'm too lazy to think through now, or 2) a sign of a bad smelling management API and a real edge case. So, I won't bother dealing with that.
Closing.
> ExpressionSupportSmokeTestCase doesn't properly handle attributes with undefined required attributes
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-8085
> URL: https://issues.jboss.org/browse/WFLY-8085
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> ExpressionSupportSmokeTestCase is attempting to set attributes even when other required attributes are undefined. In organizeAttributes it checks if the required attribute is undefined due to the presence of a defined alternative, but if that's not the reason it tries to set the base attribute. That will fail if the required attribute is undefined simply because the base config doesn't define it.
> https://github.com/wildfly/wildfly/pull/9628 includes a workaround for this, but it's not ideal. We should look into how setExpressions works and change it from executing a bunch of individual write-attribute ops per resource to executing them all as steps in a single composite. That would remove any reason for leaving these attributes undefined. Both the base attribute and the required attribute would be set in the same composite.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months