October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9370) Fix failing SingletonTunnelTestCase

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9370?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-9370: -------------------------------------- Fixing the above issues, the test gets stuck on {noformat} at org.jgroups.stack.RouterStubManager.forAny(RouterStubManager.java:95) at org.jgroups.protocols.TUNNEL$DefaultTUNNELPolicy.sendToAllMembers(TUNNEL.java:245) at org.jgroups.protocols.TUNNEL.send(TUNNEL.java:219) at org.jgroups.protocols.TP._send(TP.java:1598) at org.jgroups.protocols.TP.down(TP.java:1514) at org.jgroups.protocols.Discovery.down(Discovery.java:440) at org.jgroups.protocols.MERGE3.down(MERGE3.java:261) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:384) at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233) at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92) at org.jgroups.protocols.pbcast.NAKACK2.send(NAKACK2.java:807) at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:510) at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:682) at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1111) at org.jgroups.protocols.FlowControl.down(FlowControl.java:347) at org.jgroups.protocols.MFC.handleDownMessage(MFC.java:123) at org.jgroups.protocols.FlowControl.down(FlowControl.java:324) at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) at org.jgroups.protocols.FORK.down(FORK.java:101) at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039) at org.jgroups.JChannel.down(JChannel.java:790) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:683) at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:172) at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:319) at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:75) at org.jgroups.blocks.Request.execute(Request.java:67) at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:373) at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:386) at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:272) at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcher.executeOnCluster(ChannelCommandDispatcher.java:101) at org.wildfly.clustering.server.singleton.PrimaryProxyService.getValue(PrimaryProxyService.java:60) at org.jboss.msc.service.ServiceControllerImpl.getValue(ServiceControllerImpl.java:1158) at org.wildfly.clustering.server.singleton.DistributedSingletonService.getValue(DistributedSingletonService.java:180) at org.jboss.msc.service.ServiceControllerImpl.awaitValue(ServiceControllerImpl.java:1166) - locked <0x00000007a33d8a00> (a org.jboss.msc.service.ServiceControllerImpl) at org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet.doGet(NodeServiceServlet.java:70) {noformat} > Fix failing SingletonTunnelTestCase > ----------------------------------- > > Key: WFLY-9370 > URL: https://issues.jboss.org/browse/WFLY-9370 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 11.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > {{SingletonTunnelTestCase(ASYNC-tunnel)#testSingletonService}} is failing consistently now. > The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be moved to the right location and renamed (i.e. drop tunnel since that has nothing to do with what it is testing). > {noformat} > &amp#27;[0m&amp#27;[31m04:44:19,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "singleton.war")]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["jboss.clustering.group.default"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => [ > "jboss.test1.service.default is missing [jboss.clustering.group.default]", > "jboss.test2.service.default is missing [jboss.clustering.group.default]" > ], > "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => { > "Services that were unable to start:" => [ > "jboss.deployment.discovery.\"singleton.war\"", > "jboss.deployment.unit.\"singleton.war\".CdiValidatorFactoryService", > "jboss.deployment.unit.\"singleton.war\".WeldStartService", > "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.JndiBindingsService", > "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.START", > "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.VIEW.\"org.jboss.as.test.clustering.TopologyChangeListener\".REMOTE", > "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.TopologyChangeListenerBean.WeldInterceptorBindingsService", > "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"com.sun.faces.config.ConfigureListener\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"javax.faces.webapp.FacetTag\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.TopologyChangeListenerServlet\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.NodeServiceServlet\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.as.test.clustering.cluster.singleton.service.ValueServiceServlet\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldInitialListener\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".START", > "jboss.deployment.unit.\"singleton.war\".component.\"org.jboss.weld.servlet.WeldTerminalListener\".WeldInstantiator", > "jboss.deployment.unit.\"singleton.war\".deploymentCompleteService", > "jboss.deployment.unit.\"singleton.war\".ejb3.client-context.registration-service", > "jboss.deployment.unit.\"singleton.war\".jndiDependencyService", > "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformation", > "jboss.deployment.unit.\"singleton.war\".moduleDeploymentRuntimeInformationStart", > "jboss.naming.context.java.app.singleton.singleton.TopologyChangeListenerBean", > "jboss.naming.context.java.app.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"", > "jboss.naming.context.java.global.singleton.TopologyChangeListenerBean", > "jboss.naming.context.java.global.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"", > "jboss.naming.context.java.module.singleton.singleton.TopologyChangeListenerBean", > "jboss.naming.context.java.module.singleton.singleton.\"TopologyChangeListenerBean!org.jboss.as.test.clustering.TopologyChangeListener\"", > "jboss.undertow.deployment.default-server.default-host./singleton", > "jboss.undertow.deployment.default-server.default-host./singleton.UndertowDeploymentInfoService" > ], > "Services that may be the cause:" => [ > "jboss.clustering.group.default", > "org.wildfly.network.socket-binding.undefined" > ] > } > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-849: --------------------------------- Fix Version/s: 1.2.0.Beta5 (was: 1.2.0.Beta6) > Rename setMechanismProperties to setSaslMechanismProperties > ----------------------------------------------------------- > > Key: ELY-849 > URL: https://issues.jboss.org/browse/ELY-849 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.2.0.Beta5 > > > If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties. > We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-849: ------------------------------------ Assignee: Darran Lofthouse > Rename setMechanismProperties to setSaslMechanismProperties > ----------------------------------------------------------- > > Key: ELY-849 > URL: https://issues.jboss.org/browse/ELY-849 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.2.0.Beta5 > > > If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties. > We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1170) The TrustManagerFactory should use a Provider from the defined Supplier<Provider[]>

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1170?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1170: ---------------------------------- Fix Version/s: 1.2.0.Beta5 (was: 1.2.0.Beta6) > The TrustManagerFactory should use a Provider from the defined Supplier<Provider[]> > ----------------------------------------------------------------------------------- > > Key: ELY-1170 > URL: https://issues.jboss.org/browse/ELY-1170 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.2.0.Beta5 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1170) The TrustManagerFactory should use a Provider from the defined Supplier<Provider[]>

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1170?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1170: ------------------------------------- Assignee: Darran Lofthouse > The TrustManagerFactory should use a Provider from the defined Supplier<Provider[]> > ----------------------------------------------------------------------------------- > > Key: ELY-1170 > URL: https://issues.jboss.org/browse/ELY-1170 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.2.0.Beta5 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1381) Update KeyStore and SSLContext definitions to use credential store references.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1381: ------------------------------------- Summary: Update KeyStore and SSLContext definitions to use credential store references. Key: ELY-1381 URL: https://issues.jboss.org/browse/ELY-1381 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Client Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.2.0.Beta5 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-174) Filter expressions do not allow all types of regular expressions

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-174?page=com.atlassian.jira.plugin... ] Yeray Borges reassigned LOGMGR-174: ----------------------------------- Assignee: Yeray Borges > Filter expressions do not allow all types of regular expressions > ---------------------------------------------------------------- > > Key: LOGMGR-174 > URL: https://issues.jboss.org/browse/LOGMGR-174 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: Yeray Borges > > Some filter expressions require regex as an argument. The parsing of the regex does not allow for all expressions to be used. For example you can't use: > {code} > substituteAll("\\s", "replaced") > {code} > The pattern fails to be parsed. Using {{substituteAll("\s", "replaced")}} results in a pattern of {{s}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1748) Drools workbench datasource on Wildfly domain.

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1748?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-1748: --------------------------------------- [~wmedvede] , can you check if this needs to be added to the docs and then close this ticket? > Drools workbench datasource on Wildfly domain. > ---------------------------------------------- > > Key: DROOLS-1748 > URL: https://issues.jboss.org/browse/DROOLS-1748 > Project: Drools > Issue Type: Bug > Affects Versions: 7.0.0.Final, 7.3.0.Final > Environment: Drools workbench on Wildfly domain cluster > Reporter: M C > Assignee: Walter Medvedeo > Priority: Critical > > After starting workbench war (version 7.3 and 7.0, both Final) on Wildfly 10.1 domain cluster, got the issues with data source. > [Server:server-one] 13:09:07,908 WARN [org.kie.workbench.common.screens.datasource.management.backend.DataSourceManagementBootstrap] (pool-14-thread-1) Initialize deployments task finished with errors: operation execution failed. :WFLYCTL0030: No resource definition is registered for address [("subsystem" => "datasources")] > Problem does not affect Wildfly standalone configuration, only domain configuration using profiles. > WFLYCTL0030 warning says the syntax problem using jboss-cli.sh. In domain cluster it's used /profile=full-ha/subsystem=datasource/... > In standalone syntax is: /subsystem=datasource/. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1748) Drools workbench datasource on Wildfly domain.

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1748?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1748: ------------------------------------- Assignee: Walter Medvedeo (was: Petr Široký) > Drools workbench datasource on Wildfly domain. > ---------------------------------------------- > > Key: DROOLS-1748 > URL: https://issues.jboss.org/browse/DROOLS-1748 > Project: Drools > Issue Type: Bug > Affects Versions: 7.0.0.Final, 7.3.0.Final > Environment: Drools workbench on Wildfly domain cluster > Reporter: M C > Assignee: Walter Medvedeo > Priority: Critical > > After starting workbench war (version 7.3 and 7.0, both Final) on Wildfly 10.1 domain cluster, got the issues with data source. > [Server:server-one] 13:09:07,908 WARN [org.kie.workbench.common.screens.datasource.management.backend.DataSourceManagementBootstrap] (pool-14-thread-1) Initialize deployments task finished with errors: operation execution failed. :WFLYCTL0030: No resource definition is registered for address [("subsystem" => "datasources")] > Problem does not affect Wildfly standalone configuration, only domain configuration using profiles. > WFLYCTL0030 warning says the syntax problem using jboss-cli.sh. In domain cluster it's used /profile=full-ha/subsystem=datasource/... > In standalone syntax is: /subsystem=datasource/. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1749) Allow Build & Deploy to execute regardless of KieContainer currently executing

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1749?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-1749: ------------------------------------- Assignee: Alexandre Porcelli (was: Edson Tirelli) > Allow Build & Deploy to execute regardless of KieContainer currently executing > ------------------------------------------------------------------------------ > > Key: DROOLS-1749 > URL: https://issues.jboss.org/browse/DROOLS-1749 > Project: Drools > Issue Type: Enhancement > Reporter: Chad Poe > Assignee: Alexandre Porcelli > > Currently, when clicking Build & Deploy the first time, an artifact is created and put in the maven repository, and a KieContainer (with the artifact GAV) is created and started on Kie Server. When doing active development on a SNAPSHOT of that GAV it would be nice if Build & Deploy could be used to create a new SNAPSHOT version in the repository which would allow for the KieScanner to pick up those changes if the container was configured to do so. > Currently, when clicking Build & Deploy a second time, an error is returned indicating that a Container already exists with container id matching the GAV of the artifact. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 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 October 2017