April 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1570) WildFlyElytronProvider fails Java Mission Control and JDK 10

by Richard Huddleston (JIRA)

Richard Huddleston created ELY-1570: --------------------------------------- Summary: WildFlyElytronProvider fails Java Mission Control and JDK 10 Key: ELY-1570 URL: https://issues.jboss.org/browse/ELY-1570 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Environment: Windows 7 - Java Mission Control - Java 10 RedHat - Wildfly 12 - Java 10 Reporter: Richard Huddleston I CAN connect to Wildfly with JConsole JVisualVM I cannot connect with Java Mission Control (JMC). I believe this is an issue with some new code that fails to recognize that "classLoader" can be null in the Java SE / Eclipse OSI environment ClassLoader classLoader = WildFlyElytronProvider.class.getClassLoader(); com.oracle.jmc.rjmx.ConnectionException caused by javax.security.sasl.SaslException [Caused by java.lang.NullPointerException] at com.oracle.jmc.rjmx.internal.RJMXConnection.connect(RJMXConnection.java:406) at com.oracle.jmc.rjmx.internal.ServerHandle.doConnect(ServerHandle.java:88) at com.oracle.jmc.rjmx.internal.ServerHandle.connect(ServerHandle.java:78) at com.oracle.jmc.console.ui.editor.internal.ConsoleEditor$ConnectJob.run(ConsoleEditor.java:73) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Caused by: javax.security.sasl.SaslException [Caused by java.lang.NullPointerException] at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:426) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) at ...asynchronous invocation...(Unknown Source) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:570) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:532) at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:520) at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:268) at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:156) at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:103) at com.oracle.jmc.rjmx.internal.RJMXConnection.connectJmxConnector(RJMXConnection.java:451) at com.oracle.jmc.rjmx.internal.RJMXConnection.establishConnection(RJMXConnection.java:427) at com.oracle.jmc.rjmx.internal.RJMXConnection.connect(RJMXConnection.java:399) ... 4 more Caused by: java.lang.NullPointerException at org.wildfly.security.WildFlyElytronProvider$ProviderService.getImplementationClass(WildFlyElytronProvider.java:429) at org.wildfly.security.WildFlyElytronProvider$ProviderService.newInstance(WildFlyElytronProvider.java:413) at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:94) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50) at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102) at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66) at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:76) at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64) at java.base/java.security.AccessController.doPrivileged(Native Method) at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64) at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1348) at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:395) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:420) at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-193) Move Ansible Files from Hawkular QE Utils to Kiali

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-193?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo updated SWSQE-193: ------------------------------------------ Sprint: Kiali QE Sprint 4 > Move Ansible Files from Hawkular QE Utils to Kiali > -------------------------------------------------- > > Key: SWSQE-193 > URL: https://issues.jboss.org/browse/SWSQE-193 > Project: Kiali QE > Issue Type: Task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-193) Move Ansible Files from Hawkular QE Utils to Kiali

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-193?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo reassigned SWSQE-193: --------------------------------------------- Team: Infrastructure (was: Infrastructure) Assignee: Guilherme Baufaker Rêgo (was: Michael Foley) > Move Ansible Files from Hawkular QE Utils to Kiali > -------------------------------------------------- > > Key: SWSQE-193 > URL: https://issues.jboss.org/browse/SWSQE-193 > Project: Kiali QE > Issue Type: Task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-193) Move Ansible Files from Hawkular QE Utils to Kiali

by Guilherme Baufaker Rêgo (JIRA)

Guilherme Baufaker Rêgo created SWSQE-193: --------------------------------------------- Summary: Move Ansible Files from Hawkular QE Utils to Kiali Key: SWSQE-193 URL: https://issues.jboss.org/browse/SWSQE-193 Project: Kiali QE Issue Type: Task Reporter: Guilherme Baufaker Rêgo Assignee: Michael Foley -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2253: -------------------------------- These are not the complete logs, what I'm interested in is especially the bind / ping addresses in FD_SOCK. Also, it would be helpful to have the VERIFY_SUSPECT protocol's log available at TRACE level, too. I see that members are suspected, only to be un-suspected a few ms later... this could point to an incorrect bind address used in FD_SOCK. > FD_SOCK is not working in AWS environment > ----------------------------------------- > > Key: JGRP-2253 > URL: https://issues.jboss.org/browse/JGRP-2253 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.10 > Environment: AWS - EC2 > Reporter: Sibin Karnavar > Assignee: Bela Ban > Fix For: 4.0.12 > > > We have our failure detection defined like below. > <FD_SOCK external_port="7804" /> > <FD timeout="3000" max_tries="3" /> > <VERIFY_SUSPECT timeout="3000" /> > Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing. > In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK. > We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port. > Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS. > Thanks, > Sibin -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-192) Include Openshift Module in Ansible Slaves

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-192?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-192. ------------------------------------------- Resolution: Done > Include Openshift Module in Ansible Slaves > ------------------------------------------ > > Key: SWSQE-192 > URL: https://issues.jboss.org/browse/SWSQE-192 > Project: Kiali QE > Issue Type: Task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > - New Test Mesh Stage [SWSQE-166] will require openshift pip module -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-184) Validate that Service-Meshes were succesfully deployed

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-184?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-184. ------------------------------------------- Resolution: Done > Validate that Service-Meshes were succesfully deployed > ------------------------------------------------------ > > Key: SWSQE-184 > URL: https://issues.jboss.org/browse/SWSQE-184 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Some automation scripts will fail if test-meshes are not up and running prior to tests being run. Thus this task is to create a script that will validate that all service-mesh pods being successfully started. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-184) Validate that Service-Meshes were succesfully deployed

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-184?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo commented on SWSQE-184: ----------------------------------------------- Added the following lines to verify it if test mesh is deployed: - name: Wait until all pods are running openshift_raw: definition: apiVersion: v1 kind: ReplicaSet metadata: name: "kiali-test-service-{{item[1]}}" namespace: "{{item[0]}}" spec: selector: matchLabels: kiali-test: "test-service-{{item[1]}}" with_nested: - ['kiali-test-depth', 'kiali-test-breath', 'kiali-test-circle', 'kiali-test-circle-callback', 'kiali-test-hourglass', 'kiali-test-box', 'kiali-test-depth-sink', 'kiali-test-breath-sink'] - ['a', 'b', 'c', 'd', 'e', 'f'] register: replicaResult until: "replicaResult.result.status.ready_replicas != 'null'" retries: 20 delay: 10 > Validate that Service-Meshes were succesfully deployed > ------------------------------------------------------ > > Key: SWSQE-184 > URL: https://issues.jboss.org/browse/SWSQE-184 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Some automation scripts will fail if test-meshes are not up and running prior to tests being run. Thus this task is to create a script that will validate that all service-mesh pods being successfully started. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-184) Validate that Service-Meshes were succesfully deployed

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-184?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo edited comment on SWSQE-184 at 4/30/18 10:02 AM: ------------------------------------------------------------------------- Added the following lines to verify it if test mesh is deployed: {code:yaml} - name: Wait until all pods are running openshift_raw: definition: apiVersion: v1 kind: ReplicaSet metadata: name: "kiali-test-service-{{item[1]}}" namespace: "{{item[0]}}" spec: selector: matchLabels: kiali-test: "test-service-{{item[1]}}" with_nested: - ['kiali-test-depth', 'kiali-test-breath', 'kiali-test-circle', 'kiali-test-circle-callback', 'kiali-test-hourglass', 'kiali-test-box', 'kiali-test-depth-sink', 'kiali-test-breath-sink'] - ['a', 'b', 'c', 'd', 'e', 'f'] register: replicaResult until: "replicaResult.result.status.ready_replicas != 'null'" retries: 20 delay: 10 {code} was (Author: gbaufake): Added the following lines to verify it if test mesh is deployed: - name: Wait until all pods are running openshift_raw: definition: apiVersion: v1 kind: ReplicaSet metadata: name: "kiali-test-service-{{item[1]}}" namespace: "{{item[0]}}" spec: selector: matchLabels: kiali-test: "test-service-{{item[1]}}" with_nested: - ['kiali-test-depth', 'kiali-test-breath', 'kiali-test-circle', 'kiali-test-circle-callback', 'kiali-test-hourglass', 'kiali-test-box', 'kiali-test-depth-sink', 'kiali-test-breath-sink'] - ['a', 'b', 'c', 'd', 'e', 'f'] register: replicaResult until: "replicaResult.result.status.ready_replicas != 'null'" retries: 20 delay: 10 > Validate that Service-Meshes were succesfully deployed > ------------------------------------------------------ > > Key: SWSQE-184 > URL: https://issues.jboss.org/browse/SWSQE-184 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Matt Mahoney > Assignee: Guilherme Baufaker Rêgo > > Some automation scripts will fail if test-meshes are not up and running prior to tests being run. Thus this task is to create a script that will validate that all service-mesh pods being successfully started. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3776) Deprecate attribute "show-model" in jmx subsystem

by Yeray Borges (JIRA)

Yeray Borges created WFCORE-3776: ------------------------------------ Summary: Deprecate attribute "show-model" in jmx subsystem Key: WFCORE-3776 URL: https://issues.jboss.org/browse/WFCORE-3776 Project: WildFly Core Issue Type: Task Components: JMX Affects Versions: 5.0.0.Alpha5 Reporter: Yeray Borges Assignee: Yeray Borges The attribute show-model is used as a switch which selects which model is exposed in the MBean server. If it is false, the model is exposed under {{jboss.as.exprs}} domain, which could return expressions on reads, if true the model is exposed under {{jboss.as}} domain, which returns the expression resolved on reads, otherwise both models are exposed. This attribute will be removed in future versions -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2018