February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3457) Reduce class loading of Elytron subsystem

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3457: ---------------------------------- Fix Version/s: 4.0.0.Alpha7 (was: 4.0.0.Beta1) > Reduce class loading of Elytron subsystem > ----------------------------------------- > > Key: WFCORE-3457 > URL: https://issues.jboss.org/browse/WFCORE-3457 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha7 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3255) Complex type AttributeDefinition variants don't handle ParameterCorrector properly

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3255: ---------------------------------- Fix Version/s: (was: 4.0.0.Beta1) > Complex type AttributeDefinition variants don't handle ParameterCorrector properly > ---------------------------------------------------------------------------------- > > Key: WFCORE-3255 > URL: https://issues.jboss.org/browse/WFCORE-3255 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called. > These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3555) Pipe with echo command gives incorrect result

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3555?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3555: ---------------------------------- Fix Version/s: 4.0.0.Alpha10 > Pipe with echo command gives incorrect result > --------------------------------------------- > > Key: WFCORE-3555 > URL: https://issues.jboss.org/browse/WFCORE-3555 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Katerina Novotna > Assignee: Martin Stefanko > Fix For: 4.0.0.Alpha10 > > > *Description of problem:* > When putting 'echo' into the right side of the pipe. Addional 'o' is displayed as result. > *Actual results:* > [standalone@embedded /] version | echo test > o test > *Expected results:* > [standalone@embedded /] version | echo test > test -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3424) Replace MSC listeners with stability monitors

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3424?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3424: ---------------------------------- Fix Version/s: 4.0.0.Alpha4 (was: 4.0.0.Beta1) > Replace MSC listeners with stability monitors > --------------------------------------------- > > Key: WFCORE-3424 > URL: https://issues.jboss.org/browse/WFCORE-3424 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 4.0.0.Alpha2 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 4.0.0.Alpha4 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3475) Tighten visibility on some AttributeDefinition fields

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3475?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3475: ---------------------------------- Fix Version/s: 4.0.0.Alpha10 > Tighten visibility on some AttributeDefinition fields > ----------------------------------------------------- > > Key: WFCORE-3475 > URL: https://issues.jboss.org/browse/WFCORE-3475 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha10 > > > AttributeDefinition and some subclasses in the controller module have some fields that are not private. This will make it problematic to evolve the management code in the future. Deprecate any that are protected, with a note to use the getter, and make package protected ones private. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3302) Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3302?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-3302: --------------------------------------- [~brian.stansberry] is this now resolved? > Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5 > --------------------------------------------------------------------------------------------- > > Key: WFCORE-3302 > URL: https://issues.jboss.org/browse/WFCORE-3302 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Fix For: 4.0.0.Alpha7 > > > This bug is about problems in WF Core management tests. I believe it exposes a flaw in how remoting handles server sockets, but AFAIK there is no impact on WF Core remoting server sockets. > Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet: > {code} > java.lang.RuntimeException: java.net.BindException: Address already in use: bind > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282) > at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372) > at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92) > at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88) > at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94) > at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346) > {code} > These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests. > I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method. > The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens: > {code} > "XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307) > - locked <0xc0d> (a java.lang.Object) > at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229) > at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) > - locked <0xc38> (a java.util.HashSet) > at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl) > - locked <0xc39> (a java.util.Collections$UnmodifiableSet) > - locked <0xc3a> (a sun.nio.ch.Util$2) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:519) > {code} > That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket. > I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed. > I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3228) WorkerServerDefinition should not be registered on a domain profile

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3228?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3228: ---------------------------------- Fix Version/s: 4.0.0.Alpha10 > WorkerServerDefinition should not be registered on a domain profile > ------------------------------------------------------------------- > > Key: WFCORE-3228 > URL: https://issues.jboss.org/browse/WFCORE-3228 > Project: WildFly Core > Issue Type: Bug > Components: IO > Affects Versions: 3.0.1.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha10 > > > Title says it all. > I think removing this isn't an incompatible change because these are runtime-only synthetic resources where WorkerResourceDefinition.WorkerResource will never produce a child resource against which an operation can be targeted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3302) Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3302?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3302: ---------------------------------- Fix Version/s: 4.0.0.Alpha7 > Intermittent protocol and controller module unit test failures since move to JBoss Remoting 5 > --------------------------------------------------------------------------------------------- > > Key: WFCORE-3302 > URL: https://issues.jboss.org/browse/WFCORE-3302 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Test Suite > Reporter: Brian Stansberry > Fix For: 4.0.0.Alpha7 > > > This bug is about problems in WF Core management tests. I believe it exposes a flaw in how remoting handles server sockets, but AFAIK there is no impact on WF Core remoting server sockets. > Since the move to JBoss Remoting 5 we've seen intermittent failures in the protocol and controller module testsuites involving the tests that use their respective copies of the ChannelServer + RemoteChannelPairSetup test fixture. These tests all do a setup and teardown of the fixture for each test method (i.e. @Before and @After) with the failure being that a test fails creating a remoting server with a failure that indicates the server from a previous test hasn't completely shut down yet: > {code} > java.lang.RuntimeException: java.net.BindException: Address already in use: bind > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:282) > at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372) > at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:92) > at org.jboss.as.controller.support.RemoteChannelPairSetup.setupRemoting(RemoteChannelPairSetup.java:88) > at org.jboss.as.controller.ModelControllerClientTestCase.setupTestClient(ModelControllerClientTestCase.java:94) > at org.jboss.as.controller.ModelControllerClientTestCase.testCloseInputStreamEntry(ModelControllerClientTestCase.java:346) > {code} > These failures have been mildly annoying on ci.wildfly.org, but now that the same code is being on other test machines, e.g. brontes used for EAP testing, they are completely intolerable, affecting a high percentage of CI runs for pull requests. > I believe the issue arises from changes to these fixtures that came in as part of the Remoting 5 upgrade such that a remoting Endpoint is not being created/shutdown for each test method. This causes a problem because the AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) *does not* synchronously close down the underlying socket as part of a call to its close() method. > The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens: > {code} > "XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307) > - locked <0xc0d> (a java.lang.Object) > at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229) > at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149) > - locked <0xc38> (a java.util.HashSet) > at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107) > at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86) > - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl) > - locked <0xc39> (a java.util.Collections$UnmodifiableSet) > - locked <0xc3a> (a sun.nio.ch.Util$2) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97) > at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:519) > {code} > That thread is not under the control of the test fixture, which means there's a race between it closing the socket and the test moving on the next setup where it tries to open the socket. > I think the only solution for this is to bring the endpoint lifecycle back under the control of the test fixture such that the fixture knows all is shutdown. I don't see anything else the test can block on to ensure the server socket is closed. > I think this would be a bug for any use of remoting where a server may quickly be shutdown and then recreated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3464) Fix build for JDK10

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3464?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3464: ---------------------------------- Fix Version/s: 4.0.0.Alpha6 > Fix build for JDK10 > ------------------- > > Key: WFCORE-3464 > URL: https://issues.jboss.org/browse/WFCORE-3464 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Scripts, Server > Environment: JDK10 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Fix For: 4.0.0.Alpha6 > > > Currently we have quite few issues when running on JDK10. > it mostly looks related to version detection code that fails to properly detect 10. > same goes for many dependent components. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3501) Allow System properties to be set at parse time before extensions are loaded in standalone mode

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3501?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3501: ---------------------------------- Fix Version/s: 4.0.0.Alpha6 > Allow System properties to be set at parse time before extensions are loaded in standalone mode > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-3501 > URL: https://issues.jboss.org/browse/WFCORE-3501 > Project: WildFly Core > Issue Type: Task > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 4.0.0.Alpha6 > > > Subject says it all, except that if the property value includes an expression and the expression cannot be resolved at parse time, the property will not be set at parse time and the logic already in place will deal with it. There should be no reason for anyone to use an expression, certainly not an unresolvable one, in a property that needs to be set before extensions are loaded. -- 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