May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2883) Unignore RemoveManagementRealmTestCase

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2883: -------------------------------------------- Summary: Unignore RemoveManagementRealmTestCase Key: WFCORE-2883 URL: https://issues.jboss.org/browse/WFCORE-2883 Project: WildFly Core Issue Type: Task Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Unignore it once CLI is based on aesh-readline. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2679) Intermittent failures in RemoveManagementRealmTestCase.testAnyCommand

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2679?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-2679: ----------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2344, https://github.com/wildfly/wildfly-core/pull/2482 (was: https://github.com/wildfly/wildfly-core/pull/2344) > Intermittent failures in RemoveManagementRealmTestCase.testAnyCommand > --------------------------------------------------------------------- > > Key: WFCORE-2679 > URL: https://issues.jboss.org/browse/WFCORE-2679 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Test Suite > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > > Test is failing intermittently in calls to ctrlCAndWaitForClose() > https://ci.wildfly.org/project.html?projectId=WildFlyCore&buildTypeId=&ta... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2882) Review & fix xml persistence of elytron subsystem

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2882?page=com.atlassian.jira.plugi... ] Tomaz Cerar updated WFCORE-2882: -------------------------------- Description: Elytron subsystem uses a mess of parsers and duplicate code in them. Go trough all parsers and unify attribute persistence with rest of the server. also get rid as much of custom parser code as possible. Update XSDs where appropriate to follow common model. was: Elytron subsystem uses a mess of parsers and duplicate code in them. Go trough all parsers and unify attribute persistence with rest of the server. also get rid as much of custom parser code as possible. > Review & fix xml persistence of elytron subsystem > ------------------------------------------------- > > Key: WFCORE-2882 > URL: https://issues.jboss.org/browse/WFCORE-2882 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Elytron subsystem uses a mess of parsers and duplicate code in them. > Go trough all parsers and unify attribute persistence with rest of the server. > also get rid as much of custom parser code as possible. > Update XSDs where appropriate to follow common model. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2882) Review & fix xml persistence of elytron subsystem

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-2882: ----------------------------------- Summary: Review & fix xml persistence of elytron subsystem Key: WFCORE-2882 URL: https://issues.jboss.org/browse/WFCORE-2882 Project: WildFly Core Issue Type: Task Components: Domain Management, Security Reporter: Tomaz Cerar Assignee: Tomaz Cerar Elytron subsystem uses a mess of parsers and duplicate code in them. Go trough all parsers and unify attribute persistence with rest of the server. also get rid as much of custom parser code as possible. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2876) runtime-failure-causes-rollback does not seem to have effect when configured in model

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2876?page=com.atlassian.jira.plugi... ] Miroslav Novak commented on WFCORE-2876: ---------------------------------------- I've modified the reproduce to fail the test if MDB does not activate after failback but could not reproduce. Let me double check this issue. It's possible that it was fixed recently. > runtime-failure-causes-rollback does not seem to have effect when configured in model > ------------------------------------------------------------------------------------- > > Key: WFCORE-2876 > URL: https://issues.jboss.org/browse/WFCORE-2876 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner > Affects Versions: 3.0.0.Beta21 > Reporter: Miroslav Novak > Assignee: ehsavoie Hugonnet > > This is follow up on discussion in WFCORE-1912. There is difference in behavior if deployment is deployed like: > {code}deploy ~/tmp/mdb1.jar --unmanaged --headers={rollback-on-runtime-failure=false}{code} > and if it's deployed by copying to deployments directory and setting {{rollback-on-runtime-failure=false}} in model: > {code} > /subsystem=deployment-scanner/scanner=default:write-attribute(name=runtime-failure-causes-rollback,value=false) > {code} > If it's deployed by the 1st way using CLI {{deploy}} command then If deployment is missing some dependencies (like connection factories, queues/topics) and those are added later then deployment is able recover from it and start working without need to reload/restart server or redeploy. > However if it's deployed the 2nd way then deployment does not recover when missing dependencies are added. It looks like attribute {{runtime-failure-causes-rollback}} does not have the effect in this case. > This is causing problems when Artemis is configured in colocated HA topology with replicated journal where it takes some time for Artemis to activate but deployment which depends on some connection factories and queues has already tried to deploy. We need deployment to recover from this situation automatically. Restart/Reload will not help in this case as it would end up in the same situation. Only manual redeploy will help which is a workaround. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2174) Discovery return_entire_cache does not work.

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2174?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2174: --------------------------- Fix Version/s: 4.0.4 > Discovery return_entire_cache does not work. > -------------------------------------------- > > Key: JGRP-2174 > URL: https://issues.jboss.org/browse/JGRP-2174 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.1 > Reporter: Masazumi Kobayashi > Assignee: Bela Ban > Fix For: 4.0.4 > > > Please Check https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/... > This line was changed in JGRP-2098. > Previous code was below. This worked fine. > sendDiscoveryResponse(addr, physical_addr, NameCache.get(addr), msg.getSrc(), isCoord(addr)); > Current code is below. > sendDiscoveryResponse(addr, physical_addr, NameCache.get(addr), msg.getSrc(), is_coord); > If this node is a coordinator, this change will cause all PingData responses to be recognized as Coord and return_entire_cache will not work properly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8856) When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description.

by Hynek Švábek (JIRA)

Hynek Švábek created WFLY-8856: ---------------------------------- Summary: When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description. Key: WFLY-8856 URL: https://issues.jboss.org/browse/WFLY-8856 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek Švábek Assignee: Darran Lofthouse When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description. There is expected quotation without backslash in failure description. *How to reproduce* *create credential store* {code} /subsystem=elytron/credential-store=cs001:add(create=true, credential-reference={clear-text=pass123},location=cs001.jceks) {code} *Try to add-alias twice and for second run you get failure description.* {code} /subsystem=elytron/credential-store=cs001:add-alias(alias=alias001, secret-value="secret_value") /subsystem=elytron/credential-store=cs001:add-alias(alias=alias001, secret-value="secret_value") { "outcome" => "failed", "result" => undefined, "failure-description" => "WFLYELY00913: Credential alias \"alias001\" of credential type \"org.wildfly.security.credential.PasswordCredential\" already exists in the store", "rolled-back" => true } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (JGRP-2174) Discovery return_entire_cache does not work.

by Masazumi Kobayashi (JIRA)

Masazumi Kobayashi created JGRP-2174: ---------------------------------------- Summary: Discovery return_entire_cache does not work. Key: JGRP-2174 URL: https://issues.jboss.org/browse/JGRP-2174 Project: JGroups Issue Type: Bug Affects Versions: 4.0.1 Reporter: Masazumi Kobayashi Assignee: Bela Ban Please Check https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/... This line was changed in JGRP-2098. Previous code was below. This worked fine. sendDiscoveryResponse(addr, physical_addr, NameCache.get(addr), msg.getSrc(), isCoord(addr)); Current code is below. sendDiscoveryResponse(addr, physical_addr, NameCache.get(addr), msg.getSrc(), is_coord); If this node is a coordinator, this change will cause all PingData responses to be recognized as Coord and return_entire_cache will not work properly. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8587) Unable to establish loopback connection

by Daniel Kittrich (JIRA)

[ https://issues.jboss.org/browse/WFLY-8587?page=com.atlassian.jira.plugin.... ] Daniel Kittrich closed WFLY-8587. --------------------------------- Resolution: Cannot Reproduce Bug > Unable to establish loopback connection > --------------------------------------- > > Key: WFLY-8587 > URL: https://issues.jboss.org/browse/WFLY-8587 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 10.1.0.Final > Environment: Windows 8.1 > Reporter: Daniel Kittrich > Assignee: Jason Greene > > When starting a fresh new installation using standalone.bat, > the system reports: > ERROR MSC000001: Failed to start service org.wildfly.io.worker.default... > caused by: "unable to establish loopback connection". > Consequently many services won't start. > Server then reports: ... started (with errors). > We believe the reported exception (WorkerService.java:55) comes from: > https://github.com/wildfly/wildfly-core/blob/2.0.10.Final/io/subsystem/sr... > *Screen dump*: > 21:19:16,682 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service org.wildfly.io.worker.default: org.jboss.msc.service.StartException in service org.wildfly.io.worker.default: java.io.IOException: > Unable to establish loopback connection > at org.wildfly.extension.io.WorkerService.start(WorkerService.java:55) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.io.IOException: Unable to establish loopback connection > at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:101) > at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:68) > at java.security.AccessController.doPrivileged(Native Method) > at sun.nio.ch.PipeImpl.<init>(PipeImpl.java:170) > at sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:50) > at java.nio.channels.Pipe.open(Pipe.java:155) > at sun.nio.ch.WindowsSelectorImpl.<init>(WindowsSelectorImpl.java:127) > at sun.nio.ch.WindowsSelectorProvider.openSelector(WindowsSelectorProvider.java:44) > at org.xnio.nio.NioXnio$DefaultSelectorCreator.open(NioXnio.java:257) > at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:97) > at org.xnio.nio.NioXnio.createWorker(NioXnio.java:212) > at org.wildfly.extension.io.WorkerService.start(WorkerService.java:53) > ... 5 more > Caused by: java.net.ConnectException: Connection timed out: connect > at sun.nio.ch.Net.connect0(Native Method) > at sun.nio.ch.Net.connect(Net.java:454) > at sun.nio.ch.Net.connect(Net.java:446) > at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:648) > at java.nio.channels.SocketChannel.open(SocketChannel.java:189) > at sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:130) > at sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:83) > ... 16 more > 21:19:16,691 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "io"), > ("worker" => "default") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.io.worker.default" => "org.jboss.msc.service.StartException in service org.wildfly.io.worker.default: java.io.IOException: Unable to establish loopback connection > Caused by: java.io.IOException: Unable to establish loopback connection > Caused by: java.net.ConnectException: Connection timed out: connect"}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.io.worker.default"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ... > 21:19:17,032 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started (with errors) in 25262ms - Started 308 of 574 services (16 services failed or missing dependencies, 393 ser > vices are lazy, passive or on-demand) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-1577) Support FIFO queue for agenda group focus

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1577?page=com.atlassian.jira.plugi... ] Edson Tirelli resolved DROOLS-1577. ----------------------------------- Resolution: Rejected > Support FIFO queue for agenda group focus > ----------------------------------------- > > Key: DROOLS-1577 > URL: https://issues.jboss.org/browse/DROOLS-1577 > Project: Drools > Issue Type: Feature Request > Affects Versions: 6.5.0.Final > Reporter: Russell Morrisey > Assignee: Mario Fusco > > When setting up the ordering of agenda groups, the framework should support adding them in the order they are supposed to be executed. > Ex: > agenda.getAgendaGroup( "calculation" ).setQueue(); > agenda.getAgendaGroup( "report" ).setQueue(); > Or, even better: > agenda.addAgendaGroupsToQueue("calculation", "report"); > And: > agenda.addAgendaGroupsToQueue(agenda.getAgendaGroup( "calculation" ), agenda.getAgendaGroup( "report" )) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

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