February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2830) Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2830?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2830: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Split testsuite/shared to distinguish things meant for sharing within the core testsuite from things usable in other projects > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2830 > URL: https://issues.jboss.org/browse/WFCORE-2830 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta2 > > > The testsuite/shared module includes two conceptually different types of code: > 1) Things that are meant to be usable across different modules in core's own testsuite. > 2) Things that we are willing to support for use in other projects that rely on WildFly Core. > Since the two things are mixed, we are essentially supporting externally things that are not intended for use outside core. And it makes it difficult to evaluate new additions to testsuite/shared, to see whether the addition is really relevant to core and to see whether proposed external use is something we want. > The purpose of WildFly Core is not to be a provider of testsuite utilities. For anything we expose for external use, there should be a substantial code maintenance benefit that comes from sharing it, something beyond avoiding code duplication. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3479) Deploying an empty deployment and adding content later fails in a composite

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3479?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3479: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Deploying an empty deployment and adding content later fails in a composite > --------------------------------------------------------------------------- > > Key: WFCORE-3479 > URL: https://issues.jboss.org/browse/WFCORE-3479 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.10.Final > Reporter: Kabir Khan > Assignee: ehsavoie Hugonnet > Fix For: 4.0.0.Beta2 > > > When adding mixed domain tests for EAP 7.1.0 I could not get the MixedDomainDeployment710TestCase.testExplodedDeployment() test to work. Comparing with the core domain ExplodedDeploymentTestCase.testInstallAndExplodeDeploymentOnDCFromScratch(), they both do the following: > {code} > 1) Create an empty deployment > 2) Add some content to the deployment using input streams > 3) Add the deployment to a server group > {code} > However, they differ in that ExplodedDeploymentTestCase does this as individual steps, while MixedDomainDeployment710TestCase does this in a composite. I have a branch at https://github.com/kabir/wildfly-core/tree/WFCORE-3479 which expands ExplodedDeploymentTestCase to demonstrate the problem. > Going back to MixedDomainDeploymentTestCase, the testExplodedDeployment() test pushes the following composite to the DC: > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [("deployment" => "test.war")], > "content" => [{"empty" => true}] > }, > { > "operation" => "add-content", > "address" => [("deployment" => "test.war")], > "content" => [ > { > "target-path" => "index.html", > "input-stream-index" => 0 > }, > { > "target-path" => "index2.html", > "input-stream-index" => 1 > } > ] > }, > { > "operation" => "add", > "address" => [ > ("server-group" => "other-server-group"), > ("deployment" => "test.war") > ], > "enabled" => true > }, > { > "operation" => "add", > "address" => [ > ("server-group" => "main-server-group"), > ("deployment" => "test.war") > ], > "enabled" => true > } > ], > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE", > "domain-uuid" => "b016e0a3-4175-4f40-b6b9-779fc0fd1745", > "execute-for-coordinator" => true > } > } > {code} > What ends up being pushed to the slave is: > {code} > { > "operation" => "composite", > "address" => [], > "steps" => [ > { > "operation" => "add", > "address" => [("deployment" => "test.war")], > "content" => [{ > "hash" => bytes { > 0x8f, 0x7c, 0x8c, 0x80, 0x35, 0x88, 0x36, 0x16, > 0x61, 0xfa, 0x0a, 0x10, 0x30, 0xf9, 0x13, 0x29, > 0x04, 0x05, 0x9d, 0x82 > }, > "archive" => false > }], > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE", > "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc" > }, > "runtime-name" => undefined > }, > { > "operation" => "add-content", > "address" => [("deployment" => "test.war")], > "content" => [{ > "hash" => bytes { > 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67, > 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9, > 0x78, 0x59, 0x91, 0x63 > }, > "target-path" => "." > }], > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE", > "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc" > }, > "path" => [ > "index.html", > "index2.html" > ] > }, > { > "operation" => "add", > "address" => [ > ("server-group" => "other-server-group"), > ("deployment" => "test.war") > ], > "enabled" => true > }, > { > "operation" => "add", > "address" => [ > ("server-group" => "main-server-group"), > ("deployment" => "test.war") > ], > "enabled" => true > } > ], > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE", > "domain-uuid" => "9f6d874e-24f8-41ec-a1d0-9c98509964fc", > "execute-for-coordinator" => true > } > } > {code} > The error reported by the DC is: > {code} > { > "outcome" => "failed", > "result" => { > "step-1" => { > "outcome" => "failed", > "rolled-back" => true > }, > "step-2" => { > "outcome" => "failed", > "rolled-back" => true > }, > "step-3" => { > "outcome" => "failed", > "rolled-back" => true > }, > "step-4" => { > "outcome" => "failed", > "rolled-back" => true > } > }, > "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}}}}}}}, > "rolled-back" => true, > "server-groups" => {"other-server-group" => {"host" => {"slave" => {"server-one" => {"response" => { > "outcome" => "failed", > "result" => { > "step-1" => { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found", > "rolled-back" => true > }, > "step-2" => {"outcome" => undefined} > }, > "failure-description" => {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"deployment\" => \"test.war\")]' not found"}}, > "rolled-back" => true > }}}}}} > } > {code} > Having debugged the slave process a bit, I *believe* the following is what is passed to the servers by the slave HC: > {code} > { > "operation" => "composite", > "steps" => [ > { > "operation" => "add-content", > "address" => [("deployment" => "test.war")], > "content" => [{ > "hash" => bytes { > 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67, > 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9, > 0x78, 0x59, 0x91, 0x63 > }, > "target-path" => "." > }], > "operation-headers" => { > "access-mechanism" => "NATIVE", > "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1" > }, > "path" => [ > "index.html", > "index2.html" > ] > }, > { > "operation" => "add", > "address" => [("deployment" => "test.war")], > "enabled" => true, > "operation-headers" => { > "access-mechanism" => "NATIVE", > "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1" > }, > "runtime-name" => "test.war", > "content" => [{ > "hash" => bytes { > 0x52, 0x3a, 0x0a, 0x7b, 0x3b, 0xae, 0x1c, 0x67, > 0x22, 0x51, 0xf6, 0x34, 0xb5, 0x3b, 0xe7, 0xf9, > 0x78, 0x59, 0x91, 0x63 > }, > "archive" => false > }] > } > ], > "operation-headers" => { > "access-mechanism" => "NATIVE", > "domain-uuid" => "2bd6c01d-a844-43fc-8d10-7d6e4c32e5b1" > }, > "address" => [] > } > {code} > Note that 'add-content' now comes BEFORE 'add', which would explain the "Management resource '[(\"deployment\" => \"test.war\")]' not found". -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3386) Add configuration required to support JASPIC to the Elytron subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3386?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3386: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Add configuration required to support JASPIC to the Elytron subsystem > --------------------------------------------------------------------- > > Key: WFCORE-3386 > URL: https://issues.jboss.org/browse/WFCORE-3386 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3382) Further Enhance Elytron Permission Configuration

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3382: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Further Enhance Elytron Permission Configuration > ------------------------------------------------ > > Key: WFCORE-3382 > URL: https://issues.jboss.org/browse/WFCORE-3382 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Beta2 > > > This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location. > Finding a way for the default required permissions to be defined in one location could help eliminate the duplication. > We could also consider going one step further and subsystems register the default permissions that should be granted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3360) Eliminate org.wildfly.extension.elytron.ProviderUtil

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3360?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3360: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Eliminate org.wildfly.extension.elytron.ProviderUtil > ---------------------------------------------------- > > Key: WFCORE-3360 > URL: https://issues.jboss.org/browse/WFCORE-3360 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta2 > > > WildFly Elytron contains a public utility class org.wildfly.security.util.ProviderUtil for the same purpose, we should use the code within WildFly Elytron and not custom code within the subsystem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3255) Complex type AttributeDefinition variants don't handle ParameterCorrector properly

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3255: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Complex type AttributeDefinition variants don't handle ParameterCorrector properly > ---------------------------------------------------------------------------------- > > Key: WFCORE-3255 > URL: https://issues.jboss.org/browse/WFCORE-3255 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta2 > > > If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called. > These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3591) Add Elytron Web undertow-servlet module

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3591?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3591: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Add Elytron Web undertow-servlet module > --------------------------------------- > > Key: WFCORE-3591 > URL: https://issues.jboss.org/browse/WFCORE-3591 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3542: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Elytron JDBC realm password mapping is not consistent with underlying implementation > ------------------------------------------------------------------------------------ > > Key: WFCORE-3542 > URL: https://issues.jboss.org/browse/WFCORE-3542 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta2 > > > There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it. > The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3527: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Remove OSGi obsolete code > ------------------------- > > Key: WFCORE-3527 > URL: https://issues.jboss.org/browse/WFCORE-3527 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 4.0.0.Alpha5 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 4.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3519) Add JASPI Module

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3519?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-3519: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Add JASPI Module > ---------------- > > Key: WFCORE-3519 > URL: https://issues.jboss.org/browse/WFCORE-3519 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta2 > > > (Copy from WildFly) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2018