[JBoss JIRA] (WFLY-3860) Improve dependency handling in clustering/infinispan subsystem tests
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3860?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-3860:
--------------------------------------
Assignee: (was: Brian Stansberry)
I'm removing myself as assignee here as I don't expect to get back to this. If you don't decide to close this please feel free to grab anything useful from the previous PR.
> Improve dependency handling in clustering/infinispan subsystem tests
> --------------------------------------------------------------------
>
> Key: WFLY-3860
> URL: https://issues.jboss.org/browse/WFLY-3860
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brian Stansberry
>
> The subsystem tests in clustering/infinispan are not configured to use a controller operating in --admin-only mode, but they are also not doing all the needed setup to have needed services and resources (core, jmx, jgroups) available for when the services they add are started.
> This is fragile, because all sorts of stuff is failing when things are getting launched, but the tests are not noticing that. That's ok right now, but it could lead to missing regressions.
> Also, the changes I'm making for WFCORE-102 mean these problems will no longer go unnoticed and the tests will fail.
> I plan to:
> 1) Shifts tests to using --admin-only in cases where the tests are clearly not testing anything related to runtime execution; i.e. they are just testing model.
> 2) For OperationSequencesTestCase and OperationsTestCase, where there is some validation of runtime behavior going on (explicit in some places; in others perhaps expected, perhaps not) I'm going to switch the tests to a more focused config file that:
> a) Only uses local caches, to avoid pulling in requirements for jgroups things that are not present. (I see no indication any of the tests are testing anything not present with local caches.)
> b) Uses start="LAZY". This means services will get registered, but not started. Not starting avoids detection of various missing dependencies, including a ModuleLoader dependency that I can't figure out how to satisfy.
> The tests can't be trying to validate any behavior when services start, because they've never been able to start. So LAZY is fine. Some tests do seem to be looking for problem related to service conflicts as resources are added/removed. These tests are still valid, because service conflicts happen as soon as services are installed, whether or not the services need to start.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1160:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Definition of capabilities where the service return type is generic.
> --------------------------------------------------------------------
>
> Key: WFCORE-1160
> URL: https://issues.jboss.org/browse/WFCORE-1160
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Darran Lofthouse
> Labels: affects_elytron
>
> Within Elytron we have the following interface: -
> {code}
> public interface SecurityFactory<T> {}
> {code}
> It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations.
> As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFLY-6616) Problems in DomainHostExcludes700TestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6616?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-6616:
--------------------------------------
Assignee: Ken Wills (was: Brian Stansberry)
[~luck3y] I'm not sure on the priority on this as I don't really understand what the problem is (not surprising given I've done zero investigation.) But I'm clearing out stuff assigned to myself and for this one rather than unassigning I figured I'd pass to you since Kabir's comment talks about ignore-unused-configuration and you're the guru on that.
> Problems in DomainHostExcludes700TestCase
> -----------------------------------------
>
> Key: WFLY-6616
> URL: https://issues.jboss.org/browse/WFLY-6616
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Ken Wills
> Labels: domain-mode
> Fix For: 11.0.0.Beta1
>
>
> The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."},
> "rolled-back" => true
> }
> {code}
> And we also see an error in
> {code}
> DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1>
> {code}
> Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFLY-6616) Problems in DomainHostExcludes700TestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6616?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6616:
-----------------------------------
Issue Type: Bug (was: Feature Request)
> Problems in DomainHostExcludes700TestCase
> -----------------------------------------
>
> Key: WFLY-6616
> URL: https://issues.jboss.org/browse/WFLY-6616
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Brian Stansberry
> Labels: domain-mode
> Fix For: 11.0.0.Beta1
>
>
> The profile clone operation in the new DomainHostExcludes700TestCase.test003PostBootUpdates() in testsuite/mixed-domain fails with the following message:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.messaging.activemq.server.default' is already registered in context 'profile=clone'."},
> "rolled-back" => true
> }
> {code}
> And we also see an error in
> {code}
> DomainHostExcludes700TestCase.test001SlaveBoot:45->DomainHostExcludesTest.test001SlaveBoot:217->DomainHostExcludesTest.checkSocketBindingGroups:300 ["full-ha-sockets"] expected:<2> but was:<1>
> {code}
> Some WIP to create this test is in my https://github.com/kabir/wildfly/tree/WFLY-6616 branch
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2041) Improve query operation for complex attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2041?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2041:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Improve query operation for complex attributes
> ----------------------------------------------
>
> Key: WFCORE-2041
> URL: https://issues.jboss.org/browse/WFCORE-2041
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Lin Gao
>
> The global {{query()}} operation works only for simple attributes like:
> {code:java}
> [standalone at localhost:9990 /] /subsystem=datasources/jdbc-driver=*:query(select=[driver-xa-datasource-class-name], where={driver-name=h2})
> {
> "outcome" => "success",
> "result" => [{
> "address" => [
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "h2")
> ],
> "outcome" => "success",
> "result" => {"driver-xa-datasource-class-name" => "org.h2.jdbcx.JdbcDataSource"}
> }]
> }
> {code}
> It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are +inside of the complex attribute+, so that, for example, the following commands can work well as expected:
> {code:}
> [standalone at localhost:9990 /] /core-service=capability-registry:query(select=[possible-capabilities],where={possible-capabilities.name=org.wildfly.data-source})
> {code}
> {code:}
> [standalone at localhost:9990 /] /deployment=batch-chunk.war/subsystem=jaxrs/rest-resource=*:query(select=["rest-resource-paths"], where={"rest-resource-paths.resource-path"=>"batch/jobs"})
> {code}
> The {{rest-resource-paths.resource-path}} and {{possible-capabilities.name}} in 'where' parameter are proposed attribute names in enhanced syntax, other options maybe possible too.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2042) Improve query operation for nested child resources
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2042?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2042:
----------------------------------------
Assignee: (was: Brian Stansberry)
> Improve query operation for nested child resources
> --------------------------------------------------
>
> Key: WFCORE-2042
> URL: https://issues.jboss.org/browse/WFCORE-2042
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Lin Gao
>
> This is another similar RFE as WFCORE-2041.
> It would be good if the 'query()' operation can filter the resources by specifying value of attributes which are +inside of nested child resources(not only by the first level of child resource)+, so that, for example, the following command can work well as expected:
> {code:}
> [standalone@localhost:9990 /] /subsystem=security:query(select=[security-domain], where={security-domain.authentication.login-modules.code=RealmDirect})
> {
> "outcome" => "success",
> "result" => undefined
> }
> // here the expected output are the security-domain resources which have the loging-module RealmDirect defined.
> {code}
> The {{security-domain.authentication.login-modules.code}} in 'where' parameter is proposed attribute name in enhanced syntax, other options maybe possible.
> The different requirements between this WFCORE-2042 and WFCORE-2041 are:
> * WFCORE-2041 focus on complex attributes in one management resource
> * WFCORE-2042 focus on nested management resources with or without complex attributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (WFCORE-2197) ability to upload content from secure web server
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2197?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2197:
----------------------------------------
Assignee: (was: Brian Stansberry)
> ability to upload content from secure web server
> ------------------------------------------------
>
> Key: WFCORE-2197
> URL: https://issues.jboss.org/browse/WFCORE-2197
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Ian Kent
>
> We use the upload-deployment-url operation of wildfly management API to add content to content repository (app war) from remote web server (nexus artifact repository manager). As the nexus web server is secure so the wildfly app server needs to pass credentials to nexus when downloading war to wildfly content repository for deployment. Is there a way to encode the nexus username and password in url parameter or add a additional parameters for username and password.
--
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 reassigned WFCORE-2217:
----------------------------------------
Assignee: (was: Brian Stansberry)
> 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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month