January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2336) Remove ModelController.createClient

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2336: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Remove ModelController.createClient > ----------------------------------- > > Key: WFCORE-2336 > URL: https://issues.jboss.org/browse/WFCORE-2336 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2235) Intermittent module loading failure in InterdependentDeploymentTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2235: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Intermittent module loading failure in InterdependentDeploymentTestCase > ----------------------------------------------------------------------- > > Key: WFCORE-2235 > URL: https://issues.jboss.org/browse/WFCORE-2235 > Project: WildFly Core > Issue Type: Bug > Components: Modules, Server > Affects Versions: 4.0.0.Alpha6 > Reporter: Brian Stansberry > Assignee: Richard Opalka > Fix For: 4.0.0.Beta1 > > Attachments: WFCORE-2235svcdump.txt > > > InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional. > The test intermittently fails due to a ModuleLoadException while deploying one of the modules: > https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore... > The most notable bit of info in the log is: > {code} > 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar > at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834) > at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472) > at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457) > at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370) > at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147) > at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270) > at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68) > ... 6 more > {code} > The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar. > The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1960: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 4.0.0.Beta1 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+...) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1944: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1649: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 4.0.0.Beta1 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2365) Review custom-modifiable-realm resource in Elytron subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2365: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Review custom-modifiable-realm resource in Elytron subsystem > ------------------------------------------------------------ > > Key: WFCORE-2365 > URL: https://issues.jboss.org/browse/WFCORE-2365 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Fix For: 4.0.0.Beta1 > > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3181) Review CustomCredentialSecurityFactoryTestCase

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3181: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Review CustomCredentialSecurityFactoryTestCase > ---------------------------------------------- > > Key: WFCORE-3181 > URL: https://issues.jboss.org/browse/WFCORE-3181 > Project: WildFly Core > Issue Type: Bug > Components: Security, Test Suite > Reporter: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'. > The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory. > Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail. > If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3107) Allow slave hosts to ignore missing RBAC config resources

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3107?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3107: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Allow slave hosts to ignore missing RBAC config resources > --------------------------------------------------------- > > Key: WFCORE-3107 > URL: https://issues.jboss.org/browse/WFCORE-3107 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC. > If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op. > This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3073) Handle Shutdown via TERM gracefully

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3073: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > Handle Shutdown via TERM gracefully > ----------------------------------- > > Key: WFCORE-3073 > URL: https://issues.jboss.org/browse/WFCORE-3073 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ben Parees > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal. To achieve a -clean- graceful shutdown requires invoking the CLI tooling. This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. > While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course). > Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3019) The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3019: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha8) > The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-3019 > URL: https://issues.jboss.org/browse/WFCORE-3019 > Project: WildFly Core > Issue Type: Task > Components: Server > Reporter: Brian Stansberry > Assignee: James Perkins > Fix For: 4.0.0.Beta1 > > > For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own. > The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack. > So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP. > Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018