September 2016 - jboss-jira - Jboss List Archives

[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)

7 years, 9 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)

7 years, 9 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)

7 years, 9 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)

7 years, 9 months

1
0
0 / 0

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

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-782?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved WFCORE-782. ------------------------------------- Resolution: Done > Upgrade to Elytron 1.1.0.Alpha1 > ------------------------------- > > 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)

7 years, 9 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-782?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-782: ----------------------------------------- [~darranl] Is this one done? > Upgrade to Elytron 1.1.0.Alpha1 > ------------------------------- > > 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)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-887) "Deprecate" using an expression in model refs to interfaces

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-887?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-887: ------------------------------------ Fix Version/s: 3.0.0.Beta1 (was: 3.0.0.Alpha7) > "Deprecate" using an expression in model refs to interfaces > ----------------------------------------------------------- > > Key: WFCORE-887 > URL: https://issues.jboss.org/browse/WFCORE-887 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta1 > > > SocketBindingGroupResourceDefinition and OutboundSocketBindingResourceDefinition both have attributes that represent model refs to interface resources, but which also allow expressions. > Model references should not allow expressions. These were "grandfathered in" when the large scale expression support roll out happened for AS 7.2 / EAP 6.1. > There's no metadata facility to record that expression support is deprecated, but the add handler for these should log a WARN if they encounter an expression. Hopefully in EAP 8 we can then remove expression support. > We should look for other cases like this too, although those changes should be separate JIRAs. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-952: ------------------------------------ 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. > Use WildFly Common for null param checks > ---------------------------------------- > > Key: WFCORE-952 > URL: https://issues.jboss.org/browse/WFCORE-952 > Project: WildFly Core > Issue Type: Task > Reporter: David Lloyd > Priority: Minor > > For each module, do the following: > * Locate any/all null param check methods in the log msg > * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed > * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-909) Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-909?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-909: ------------------------------------ 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. > Allow tests to turn on boot-time enforcement of capability resolution in an --admin-only process > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-909 > URL: https://issues.jboss.org/browse/WFCORE-909 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Priority: Minor > > The OperationContext current will not throw error during boot of an --admin-only process if required capabilities cannot all be resolved, instead simply logging an ERROR. This is to allow the process to boot and give the user an opportunity to fix the problem. > Test suites often run admin-only processes though to test management of the model without needing to be concerned about runtime services. For these tests, failing on boot if required capabilities are not present may be desired. In particular, it's desirable for WF full's ParseAndMarshalModelsTestCase. So this task is to use a "jboss.unsupported.validate.boot.capabilities" system property to turn on capability resolution enforcement. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1054) Better subsystem test coverage

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1054?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1054: ------------------------------------- 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. > Better subsystem test coverage > ------------------------------ > > Key: WFCORE-1054 > URL: https://issues.jboss.org/browse/WFCORE-1054 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Kabir Khan > Assignee: Kabir Khan > > The subsystem and core-model tests should be expanded to test FULL models. In many(?) cases these tests do not use a full xml. We should generate a full xml file for testing, possibly by using the schema. Or by inspecting the resource registrations a bit similar to the ExpressionSupportTestCase. > We might need something to deal with the case where e.g. a parent expects only one of two children to be set (i.e. there is a choice) and not both. In those cases it would be good to be able to test all possible permutations. This testing should be at least the parsing and marshalling of the main model. It is uncertain whether it will be possible to do do transformers, although perhaps we could do something like the DomainAdjusters from the mixed domain tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2016