February 2018 - jboss-jira - Jboss List Archives

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2336: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > 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.Beta2 > > > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2282) Get rid of the clientRequestExecutor in AbstractModelControllerOperationHandlerFactoryService

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2282?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2282: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Get rid of the clientRequestExecutor in AbstractModelControllerOperationHandlerFactoryService > --------------------------------------------------------------------------------------------- > > Key: WFCORE-2282 > URL: https://issues.jboss.org/browse/WFCORE-2282 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta2 > > > AbstractModelControllerOperationHandlerFactoryService creates a thread pool for handling management requests, with the goal being to limit the number of concurrently executing requests to 4, with tasks for other requests being queued. > There are other ways to do this kind of limitation that do not involve a new thread pool. See Undertow's RequestLimitHandler and related RequestLimit class for the template. > This task is to implement the equivalent in org.jboss.as.controller.remote (not as public API) and then switch the execution to the ServerService Thread Pool (on a server) or the HostControllerService Thread Pool (on an HC). > It is *not* a request to move execution to the XNIO worker task thread. That should not be done without a very clear discussion. > Part of this task is to account for the thinking that went into a fix for WFCORE-1529. IOW moving work to ServerService Thread Pool / HostControllerService Thread Pool will likely affect the optimum core sizes of those pools. This AbstractModelControllerOperationHandlerFactoryService.clientRequestExecutor is what is referred to in the PR for WFCORE-1529 in its discussion of "management-handler-thread". -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2252: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > AttributeDefinition should reject configs with a default value that are also set as required > -------------------------------------------------------------------------------------------- > > Key: WFCORE-2252 > URL: https://issues.jboss.org/browse/WFCORE-2252 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta2 > > > If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value. > AttributeDefinition should reject the combination of a default value and required=true in its constructor. > I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2235: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > 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.Beta2 > > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2093) A 'start' operation only is available for a domain server resource when it is started

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2093?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2093: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > A 'start' operation only is available for a domain server resource when it is started > ------------------------------------------------------------------------------------- > > Key: WFCORE-2093 > URL: https://issues.jboss.org/browse/WFCORE-2093 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Labels: domain-mode > Fix For: 4.0.0.Beta2 > > > The server lifecycle ops are registered with the domain server resource by a call to ServerConfigResourceDefintion.registerServerLifecycleOperations. DomainModelControllerService registers that when the server registers with the HC. > This is odd in the case of 'start' as it means that op is only registered when the server is started. > Perhaps it should be registered with StoppedServerResource, although I haven't dug into what happens with that resource when the server is registered. If it is simply ignored that would be great. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1960: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > 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.Beta2 > > 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, 2 months

1
0
0 / 0

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

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1944: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > 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.Beta2 > > > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from full to core

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2746: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Move elytron management security tests from full to core > -------------------------------------------------------- > > Key: WFCORE-2746 > URL: https://issues.jboss.org/browse/WFCORE-2746 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta2 > > > Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested. > Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723 > There are a number of aspects to this, for which I'll create subtasks. > Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list. > -org.jboss.as.test.integration.security.perimeter.* [2]- > -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase- > -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]- > -org.jboss.as.test.integration.security.credentialreference [2]- > integration/elytron/ > [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now. > [2] Currently using Arquillian. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2719) Better use of the ManagementResourceRegistration data in JMX query handling

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2719?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2719: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Better use of the ManagementResourceRegistration data in JMX query handling > --------------------------------------------------------------------------- > > Key: WFCORE-2719 > URL: https://issues.jboss.org/browse/WFCORE-2719 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, JMX > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta2 > > > For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match. > Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code} > No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level. (Remember, the key/value pairs in an ObjectName are not required to be in a particular order so we can't assume the order matches the order of key/value pairs in a PathAddress. So we'd have to look for any resource with an address with a PathElement at any position whose key is 'j2eetype' or 'socket-binding'.) > Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify on those parts of the tree where a Resource search is necessary. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2669) Deprecate setValidator method in builders for ListAttributeDefinition and MapAttributeDefinition

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2669?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-2669: ------------------------------- Fix Version/s: 4.0.0.Beta2 (was: 4.0.0.Beta1) > Deprecate setValidator method in builders for ListAttributeDefinition and MapAttributeDefinition > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2669 > URL: https://issues.jboss.org/browse/WFCORE-2669 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > Fix For: 4.0.0.Beta2 > > > Let's discuss before doing anything on this. > For lists and maps, the builder call to setValidator is really a call to setElementValidator, with a call to set[List|Map]Validator being necessary if some special validation of the overall list/map is desired. > We should deprecate setValidator to help emphasize to people that really setElementValidator is what is happening. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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