August 2015 - jboss-jira - Jboss List Archives

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

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-459: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > 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: Alexey Loubyansky > Fix For: 2.0.0.CR1 > > > 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 (v6.3.15#6346)

10 years, 10 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 James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-396: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > 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: Feature Request > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 2.0.0.CR1 > > > 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 (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-384) Server does wrongly reference a list of socket binding groups

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-384?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-384: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Server does wrongly reference a list of socket binding groups > ------------------------------------------------------------- > > Key: WFCORE-384 > URL: https://issues.jboss.org/browse/WFCORE-384 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Heiko Braun > Assignee: Ken Wills > Fix For: 2.0.0.CR1 > > > hbraun: i see that a server (host=foo/server=bar) can have a list of socket-binding-groups > [10:59am] hbraun: shouldn't that be a a single socket binding instead? > [11:00am] emuckenhuber: oh... yeah > [11:00am] hbraun: maybe it's just the description that's wrong > [11:00am] emuckenhuber: that sounds similar to the jvm thing we had -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-365) inconsistent usage of min/max-occurs in model description

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-365?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-365: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > inconsistent usage of min/max-occurs in model description > --------------------------------------------------------- > > Key: WFCORE-365 > URL: https://issues.jboss.org/browse/WFCORE-365 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Emanuel Muckenhuber > Assignee: Brian Stansberry > Fix For: 2.0.0.CR1 > > Attachments: patch.txt > > > The usages of min/max-occurs in the model description are not consistent - e.g. missing in ResourceDescription, mostly wrong when used in the descriptionProvider or outdated examples in the documentation. > I'll attach a simple patch which should actually fix that issue in line with the documentation [1] (incl. recursive usage) and the usage of the CLI (ls -l). However there might be more to it. > [1] https://docs.jboss.org/author/display/AS71/Description+of+the+Management+... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-363: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > ManagementResourceRegistration.getOverrideModel never returns null > ------------------------------------------------------------------ > > Key: WFCORE-363 > URL: https://issues.jboss.org/browse/WFCORE-363 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 2.0.0.CR1 > > > ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct. > The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should. > This bug is the cause of the initial failure of my WFLY-2880 fix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-313) DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-313?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-313: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > DefaultOperationDescriptionProvider uses incorrect call to create reply parameter description > --------------------------------------------------------------------------------------------- > > Key: WFCORE-313 > URL: https://issues.jboss.org/browse/WFCORE-313 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 2.0.0.CR1 > > > When creating reply descriptions, DefaultOperationDescriptionProvider calls attributeDescriptionResolver.getOperationParameterDescription instead of attributeDescriptionResolver.getOperationReplyValueTypeDescription. > A fix needs to not break compatibility for existing users of the incorrect behavior; i.e. call the correct method in a try block, catch any MissingResourceException, and if caught call the incorrect method. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-862) MBeanServer returns MBean names that do not match filter

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-862?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-862: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > MBeanServer returns MBean names that do not match filter > -------------------------------------------------------- > > Key: WFCORE-862 > URL: https://issues.jboss.org/browse/WFCORE-862 > Project: WildFly Core > Issue Type: Bug > Components: JMX > Affects Versions: 2.0.0.Alpha12 > Reporter: Thomas Diesler > Assignee: Kabir Khan > Fix For: 2.0.0.CR1 > > > This code > {code} > MBeanServer server = ManagementFactory.getPlatformMBeanServer(); > for (ObjectName oname : server.queryNames(new ObjectName("*:type=context,*"), null)) { > System.out.println(oname); > } > {code} > gives > {code} > 16:51:25,842 INFO [stdout] (pool-3-thread-1) org.apache.camel:context=swagger-test,type=context,name="swagger-test" > 16:51:25,842 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEServer,name=default > 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=JVM,name=default,J2EEServer=default > 16:51:25,843 INFO [stdout] (pool-3-thread-1) jboss.jsr77:j2eeType=J2EEDomain,name=jboss.jsr77 > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-842) Rename CapabilityContext to CapabilityScope

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-842?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-842: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Rename CapabilityContext to CapabilityScope > ------------------------------------------- > > Key: WFCORE-842 > URL: https://issues.jboss.org/browse/WFCORE-842 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 2.0.0.CR1 > > > I used the interface name "CapabilityContext" for the thing that defines the scope in which a capability is registered. Bad name, particularly now that the WFCORE-834 work has introduced a "CapabilityResolutionContext" object for storing temp data used during capability resolution. The 834 thing is much more of a context. > So let's rename it to CapabilityScope. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-840) Improve API on AttributeDefinitions where a capability is referenced.

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-840?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-840: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Improve API on AttributeDefinitions where a capability is referenced. > --------------------------------------------------------------------- > > Key: WFCORE-840 > URL: https://issues.jboss.org/browse/WFCORE-840 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Affects Versions: 2.0.0.Alpha11 > Reporter: Darran Lofthouse > Assignee: Tomaz Cerar > Fix For: 2.0.0.CR1 > > > Take the following method call defining an attribute: - > {code} > .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true) > {code} > This definition says this attribute references something which provides the PROVIDERS_CAPABILITY. > However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY. > Really what the resource provides is not directly related to this attribute definition. > The following pull request has already improved on registering in advance what capability a resource can provide: - > https://github.com/wildfly/wildfly-core/pull/909 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-841) Patching module testsuite failure

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-841: --------------------------------- Fix Version/s: 2.0.0.CR1 (was: 2.0.0.Beta5) > Patching module testsuite failure > --------------------------------- > > Key: WFCORE-841 > URL: https://issues.jboss.org/browse/WFCORE-841 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Environment: $ java -version > java version "1.8.0_45" > Java(TM) SE Runtime Environment (build 1.8.0_45-b14) > Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) > OS X Yosemite 10.10.4 > Reporter: Brian Stansberry > Assignee: Alexey Loubyansky > Fix For: 2.0.0.CR1 > > > When running the core build locally , the 'patching' module testsuite fails: > {code} > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined. > Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase > Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase > Running org.jboss.as.patching.cli.PatchInspectUnitTestCase > Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase > testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase) Time elapsed: 0.044 sec <<< FAILURE! > java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:743) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76) > at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57) > at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180) > {code} > If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order. > Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround. > The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904 -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 10 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 August 2015