September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1694) Upgrade to WildFly Client Config 1.0.0.Beta1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1694?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1694: ------------------------------------- Fix Version/s: 3.0.0.Alpha8 (was: 3.0.0.Alpha7) > Upgrade to WildFly Client Config 1.0.0.Beta1 > -------------------------------------------- > > Key: WFCORE-1694 > URL: https://issues.jboss.org/browse/WFCORE-1694 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha8 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1693) Upgrade to JBoss Remoting 5.0.0.Beta4

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1693?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1693: ------------------------------------- Fix Version/s: 3.0.0.Alpha8 (was: 3.0.0.Alpha7) > Upgrade to JBoss Remoting 5.0.0.Beta4 > ------------------------------------- > > Key: WFCORE-1693 > URL: https://issues.jboss.org/browse/WFCORE-1693 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Remoting > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha8 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1691) Upgrade to Remoting JMX 3.0.0.Alpha1

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1691?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1691: ------------------------------------- Fix Version/s: 3.0.0.Alpha8 (was: 3.0.0.Alpha7) > Upgrade to Remoting JMX 3.0.0.Alpha1 > ------------------------------------ > > Key: WFCORE-1691 > URL: https://issues.jboss.org/browse/WFCORE-1691 > Project: WildFly Core > Issue Type: Component Upgrade > Components: JMX > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha8 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1741) read-content operation does not return the uuid of the stream as the operation result

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1741?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1741: ------------------------------------- Fix Version/s: 3.0.0.Alpha8 (was: 3.0.0.Alpha7) > read-content operation does not return the uuid of the stream as the operation result > ------------------------------------------------------------------------------------- > > Key: WFCORE-1741 > URL: https://issues.jboss.org/browse/WFCORE-1741 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Fix For: 3.0.0.Alpha8 > > > See the tail end of the discussion on WFCORE-1726. > The rules around streams in responses are: > 1) If the thing providing the stream is an attribute, the attribute value set by the read OperationStepHandler must be the uuid of the stream. > 2) If the thing providing the stream is a custom operation like :read-content, the result value in the response must be the uuid of the stream or a complex result object one of whose fields is the uuid of the stream. > Metadata about streams is propagated to the client using a response-header. But since a particular request can result in more than one attached stream, the normal non-response-header part of the result for a step must provide the uuid of the stream set by that step. This allows the client to correlate the various streams with the steps that provided them. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1733) SynchServerOperationHandler doesn't check ops for REQUIRE_RESTART properly

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1733?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1733: ------------------------------------- Fix Version/s: 3.0.0.Alpha8 (was: 3.0.0.Alpha7) > SynchServerOperationHandler doesn't check ops for REQUIRE_RESTART properly > -------------------------------------------------------------------------- > > Key: WFCORE-1733 > URL: https://issues.jboss.org/browse/WFCORE-1733 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ken Wills > Assignee: Ken Wills > Fix For: 3.0.0.Alpha8 > > > Currently, SyncServerStateOperationHandler makes a simple check to determine if the result of an op should put a server into restart-required. This should be fixed to check the AttributeDefinition for the target of a write-attribute for restart-required, and the OperationDefinition of all other ops. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFCORE-91: ----------------------------------- Fix Version/s: (was: 3.0.0.Alpha7) I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 CR1. > Review use of Locale in toLowerCase() calls > ------------------------------------------- > > Key: WFCORE-91 > URL: https://issues.jboss.org/browse/WFCORE-91 > Project: WildFly Core > Issue Type: Task > Components: CLI, Domain Management > Reporter: Brian Stansberry > > There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed: > {code} > $ git grep "toLowerCase()" > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase()); > controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase(); > core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress > domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc > domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor > host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo > host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase(); > server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase(); > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + " > testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow > testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-782) Upgrade to Elytron 1.1.0.Beta8

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-782?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-782: ------------------------------------ Summary: Upgrade to Elytron 1.1.0.Beta8 (was: Upgrade to Elytron 1.1.0.Alpha1) > Upgrade to Elytron 1.1.0.Beta8 > ------------------------------ > > Key: WFCORE-782 > URL: https://issues.jboss.org/browse/WFCORE-782 > Project: WildFly Core > Issue Type: Sub-task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha7 > > > This will also require the SSL Explorer copyright notice including within the WildFly distribution. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-234) Inconsistent synchronization in ConfigurationFile

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-234?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-234: ------------------------------------ I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 CR1. > Inconsistent synchronization in ConfigurationFile > ------------------------------------------------- > > Key: WFCORE-234 > URL: https://issues.jboss.org/browse/WFCORE-234 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha11 > Reporter: Brian Stansberry > Fix For: 3.0.0.Alpha7 > > > ConfigurationFile synchronizes on itself in some places and not in others. This may cause problems, particularly with the history dir. > The one that comes to mind is successfulBoot is synchronized, but all the methods called by ConfigurationFilePersistenceResource are not. The latter is called with the controller lock held, but the former is not. So there's a possibility of two threads interacting with the files concurrently if an operation executes immediately after boot. > The deployment scanner schedules such an op, so it's possible. Currently the schedule is for 200 ms after deployment-scanner add runs during boot. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-710) Make ServerOperationResolver handle deployment-overlays similarly to deployments

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-710?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-710: ------------------------------------ Fix Version/s: (was: 3.0.0.Alpha7) I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1. Note also that this may be considered as an incompatible behavior change, so it needs vetting before work starts. > Make ServerOperationResolver handle deployment-overlays similarly to deployments > -------------------------------------------------------------------------------- > > Key: WFCORE-710 > URL: https://issues.jboss.org/browse/WFCORE-710 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.0.Alpha2 > Reporter: Kabir Khan > > Currently in domain mode a > {code} > /deployment-overlay=xxx:add(...) > {code} > results in a deployment overlay on ALL servers. > However for deployments > {code} > /deployment=xxx:add(...) > {code} > does not get pushed to the servers. This happens when it is associated with a server group: > {code} > /server-group=zzz/deployment=xxx:add(...) > {code} > Similarly > {code} > /deployment-overlay=xxx:add(...) > {code} > should not get pushed to the servers, until we have a > {code} > /server-group=zzz/deployment=yyy:add(...) > {code} > which picks out the servers we want to have the overlay -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-406) Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true"

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-406?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-406: ------------------------------------ Fix Version/s: (was: 3.0.0.Alpha7) I'm unscheduling this to try and get the 3.0 task list down to bugs, EAP 7.1 features or stuff we know is coming. Let me know if it's likely to happen for 3.0 Beta1. > Resource description for platform mbean properties that throw UnsupportedOperationException should say nillable="true" > ---------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-406 > URL: https://issues.jboss.org/browse/WFCORE-406 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Environment: FreeBSD, OpenJDK 1.6 > Reporter: Brian Stansberry > Priority: Minor > > Some platform mbean getters are documented to throw a UOE on some VMs. The read-resource handler will catch the UOE and leave the attribute undefined, but the description says it's not nillable. > Specifically, PlatformMBeanDescriptions.getThreadingResource()'s THREAD_CPU_TIME_ENABLED attribute, although there may well be others. > This leads to this unit test failure on jvms where the UOE is thrown: > failure message="thread-cpu-time-enabled is undefined" > type="junit.framework.AssertionFailedError">junit.fra mework.AssertionFailedError: thread-cpu-time-enabled is undefined > at junit.framework.Assert.fail(Assert.java:50) > at junit.framework.Assert.assertTrue(Assert.java:20) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.validateResource(PlatformMBeanResourceUn > itTestCase.java:595) > at org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.basicResourceTest(PlatformMBeanResourceUnitTestCase.java:563) > at > org.jboss.as.platform.mbean.PlatformMBeanResourceUnitTestCase.testThreadingMXBean(PlatformMBeanResourceUnitTestCase.java:340) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 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 September 2016