February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2284) Core model test of host.xml paths are messed up

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2284: ---------------------------------------- Summary: Core model test of host.xml paths are messed up Key: WFCORE-2284 URL: https://issues.jboss.org/browse/WFCORE-2284 Project: WildFly Core Issue Type: Bug Components: Domain Management, Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 3.0.0.Alpha25 While working on https://github.com/wildfly/wildfly-core/pull/2163 Paul Ferraro noticed that HostSpecifiedPathsTestCase was creating a Resource for which there was no corresponding MRR, which his fix then had to handle. Doing that is wrong so I went to clean it up and found that the tests in this package are using incorrect model structures. So I'll clean that up. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-396: ------------------------------------ Issue Type: Enhancement (was: Feature Request) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-396: ----------------------------------------- I changed this to Enhancement as there's no real user-controllable feature here. > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta1 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-389) Alllow non persistent configuration(runtime) changes for server groups and domain using CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-389?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-389: ------------------------------------ Fix Version/s: 4.0.0.Beta1 (was: 3.0.0.Beta1) > Alllow non persistent configuration(runtime) changes for server groups and domain using CLI > ------------------------------------------------------------------------------------------- > > Key: WFCORE-389 > URL: https://issues.jboss.org/browse/WFCORE-389 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Shay Matasaro > Assignee: Brian Stansberry > Labels: EAP > Fix For: 4.0.0.Beta1 > > > Using the CLI , It is currently not possible to make runtime config changes to multiple servers , unless you are using a roll-out plan > One example is the ability to disable a mod-cluster context on multiple servers at once. > Since this operation does not affect the persistent server config it is currently not supported. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-388) Overall 'server-state' flag on the Host Controller

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-388?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-388: ------------------------------------ Fix Version/s: (was: 3.0.0.Beta1) > Overall 'server-state' flag on the Host Controller > -------------------------------------------------- > > Key: WFCORE-388 > URL: https://issues.jboss.org/browse/WFCORE-388 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > > This is for consideration; we need to see if it makes sense. > Request is for an attribute on the HC that indicates aggregate 'server-state'. The desire is to know when all servers are available, and thus it is safe to invoke management ops knowing all servers will receive them. > The only reason a server wouldn't receive an op is if it is started in a non-blocking mode, so the server gets its config but then hasn't connected with the HC and therefore won't get update operations. Starting the server in blocking mode will avoid this situation (as could changes to how we start servers, to make it more like how a slave HC registers with the master HC). So, before doing this let's first look at how to reduce/eliminate the use case for it. > Also to consider when looking at this is how to represent servers in things like "restart-required" state in this overall aggregate 'server-state'. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-459: ----------------------------------------- [~jdenise] Very few are. In most cases there's no need for any grouping beyond the resource itself. Anything on this should be deferred to WF Core 4, as it's late for 3. Re: the sorting of attributes in the server's read-resource response, I believe they may be sorted by group if there is one, but QE has filed a JBEAP to get rid of that and always sort by name . We'll likely follow through on that. In a higher level view like 'ls', grouping provides benefit, assuming the group is displayed. But for low-level read-resource the group name is not part of the output, and in that case sorting the attributes by group ends up producing what looks like a random sort. > Account for attribute groups in CLI behavior > -------------------------------------------- > > Key: WFCORE-459 > URL: https://issues.jboss.org/browse/WFCORE-459 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Beta1 > > > See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html > This JIRA is for reflecting the attribute group notion in CLI behavior. > I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-391) Add management API descriptions for alias resources and attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-391: ------------------------------------ Fix Version/s: (was: 3.0.0.Beta1) > Add management API descriptions for alias resources and attributes > ------------------------------------------------------------------ > > Key: WFCORE-391 > URL: https://issues.jboss.org/browse/WFCORE-391 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > > When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship. > For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-391) Add management API descriptions for alias resources and attributes

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-391?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-391: ------------------------------------ Issue Type: Enhancement (was: Feature Request) > Add management API descriptions for alias resources and attributes > ------------------------------------------------------------------ > > Key: WFCORE-391 > URL: https://issues.jboss.org/browse/WFCORE-391 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > > When a resource or an attribute is an alias for a different resource or attribute, the management API description data should include information describing that relationship. > For an attribute, an alias relationship is different from an 'alternatives' relationship, as the latter is a mutually exclusive arrangement (one alternative must be undefined if the other isn't) while with an alias, both attributes will exist but will always have the same value, and attempting to set them to different values (e.g. using both as params with different values in an 'add' op) is invalid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-972) Provide a way to correlate HTTP management requests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-972?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-972: ----------------------------------------- Should this be X-Correlation-ID? That shows up as a non-standard header on Wikipedia. Following the non-standard standard has pros and cons that I don't understand well enough to judge between. So I'm just asking not recommending. > Provide a way to correlate HTTP management requests > --------------------------------------------------- > > Key: WFCORE-972 > URL: https://issues.jboss.org/browse/WFCORE-972 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Heiko Braun > Assignee: Heiko Braun > Fix For: 3.0.0.Beta1 > > > {noformat} > public class CorrelationHandler implements HttpHandler { > private static final HttpString HEADER = new HttpString("X-CORR-ID"); > private final HttpHandler next; > public CorrelationHandler(HttpHandler next) { > this.next = next; > } > @Override > public void handleRequest(HttpServerExchange exchange) throws Exception { > String corr = exchange.getRequestHeaders().getFirst(HEADER); > if(corr != null) { > exchange.getResponseHeaders().put(HEADER, corr); > } > next.handleRequest(exchange); > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-785) Improve capability related error messages

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-785?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-785: ------------------------------------ Fix Version/s: 4.0.0.Beta1 (was: 3.0.0.Beta1) > Improve capability related error messages > ----------------------------------------- > > Key: WFCORE-785 > URL: https://issues.jboss.org/browse/WFCORE-785 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > When operation handlers request non-existent capabilities, the error messages aren't particularly helpful. For example: > /"WFLYCTL0158: Operation handler failed: java.lang.IllegalStateException: WFLYCTL0364: Capability 'org.wildfly.data-source.invalid' is unknown." > This is largely because it's the CapabilityRegistry that throws the exceptions, and it doesn't have much context about why the capability is needed to use in a better error message. > Likely solutions are: > 1) If CapabilityRegistryImpl has more context than is being used, look into using it. > 2) Provide more context to CapabilityRegistry (I don't much like this one; providing parameters to a call only for use in a failure message is smelly to me.) > 3) Use a custom exception type when the capability is missing, instead of ISE, and have OperationContextImpl catch that and add contextual information. > I expect 3) is the likely solution. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 2017