[JBoss JIRA] (WFLY-10314) Futures returned by CommandDispatcher.submitOnCluster(...) throws ClassCastException on get() if target node has no corresponding CommandDispatcher
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-10314:
-----------------------------------
Summary: Futures returned by CommandDispatcher.submitOnCluster(...) throws ClassCastException on get() if target node has no corresponding CommandDispatcher
Key: WFLY-10314
URL: https://issues.jboss.org/browse/WFLY-10314
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 12.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
CommandDispatcher.executeOnNode(...) is used to execute a given command on a given member of the cluster. However, the target member does not have an active CommandDispatcher to receive the command, the resulting behavior is not handled, and the caller receives a ClassCastException. This is because the RspFilter contained in the RspOptions as passed to the MessageDispatcher is not invoked for unicast requests.
The API will likely need to be adjusted/documented to define what behavior to expect in this scenario.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-10313) CommandDispatcher.executeOnNode(...) throws ClassCastException if target node has no corresponding CommandDispatcher
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-10313:
-----------------------------------
Summary: CommandDispatcher.executeOnNode(...) throws ClassCastException if target node has no corresponding CommandDispatcher
Key: WFLY-10313
URL: https://issues.jboss.org/browse/WFLY-10313
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 12.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
CommandDispatcher.executeOnNode(...) is used to execute a given command on a given member of the cluster. However, the target member does not have an active CommandDispatcher to receive the command, the resulting behavior is not handled, and the caller receives a ClassCastException. This is because the RspFilter contained in the RspOptions as passed to the MessageDispatcher is not invoked for unicast requests.
The API will likely need to be adjusted/documented to define what behavior to expect in this scenario.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-10312) messaging-activemq-colocated configuration is invalid
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-10312:
-----------------------------------
Summary: messaging-activemq-colocated configuration is invalid
Key: WFLY-10312
URL: https://issues.jboss.org/browse/WFLY-10312
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 12.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
broadcast/discovery-group attribute jgroups-channel="activemq-cluster" should read jgroups-cluster="activemq-cluster".
This was changed in the regular subsystem xml, but not the colocated xml.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-10297) Datasource clearStatistics operation clears things it shouldn't
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10297?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-10297:
---------------------------------------
Component/s: JCA
Assignee: Stefano Maestri (was: Jason Greene)
> Datasource clearStatistics operation clears things it shouldn't
> ---------------------------------------------------------------
>
> Key: WFLY-10297
> URL: https://issues.jboss.org/browse/WFLY-10297
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 12.0.0.Final
> Reporter: Rich DiCroce
> Assignee: Stefano Maestri
>
> Executing the clearStatistics operation on a datasource pool seems to zero everything, but there are some attributes that should not be affected. For example, after clearing statistics, ActiveCount, InUseCount, and IdleCount all report zero even though my database clearly shows some active connections.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFLY-10311) Eliminate comments from the standard domain mode xml config files
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10311?page=com.atlassian.jira.plugin... ]
Brian Stansberry moved WFCORE-3777 to WFLY-10311:
-------------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-10311 (was: WFCORE-3777)
Component/s: Management
(was: Management)
> Eliminate comments from the standard domain mode xml config files
> -----------------------------------------------------------------
>
> Key: WFLY-10311
> URL: https://issues.jboss.org/browse/WFLY-10311
> Project: WildFly
> Issue Type: Task
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> Comments in our standard xml config files have always been frowned upon because when the user does anything to cause config persistence the comments will be lost.
> Now, with Galleon the build won't generate those comments anyway. So get rid of them in the legacy stuff; they were always wrong and having them is not a meaningful build diff of legacy vs galleon.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (WFCORE-3777) Eliminate comments from the standard domain mode xml config files
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3777:
----------------------------------------
Summary: Eliminate comments from the standard domain mode xml config files
Key: WFCORE-3777
URL: https://issues.jboss.org/browse/WFCORE-3777
Project: WildFly Core
Issue Type: Task
Components: Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Comments in our standard xml config files have always been frowned upon because when the user does anything to cause config persistence the comments will be lost.
Now, with Galleon the build won't generate those comments anyway. So get rid of them in the legacy stuff; they were always wrong and having them is not a meaningful build diff of legacy vs galleon.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 8 months
[JBoss JIRA] (ELY-1570) WildFlyElytronProvider fails Java Mission Control and JDK 10
by Richard Huddleston (JIRA)
[ https://issues.jboss.org/browse/ELY-1570?page=com.atlassian.jira.plugin.s... ]
Richard Huddleston commented on ELY-1570:
-----------------------------------------
Thanks for the super quick response. Agreed.
JConsole and JVisualVM have jboss-client.jar as part of the classpath which turns into a "System" classLoader of type "AppClassLoader". But JMC only lets you add " jboss-client.jar " as part of the boot classpath, which results in any classes loaded having a null classloader. I can't find a way to make JMC (which is based on Eclipse) let me add jboss-client.jar as part of the class-path.
> 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, 8 months
[JBoss JIRA] (ELY-1570) WildFlyElytronProvider fails Java Mission Control and JDK 10
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1570?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1570:
----------------------------------
This appears to be caused by the usage of {{ClassLoader.loadClass()}}. A {{ClassLoader}} can legitimately be {{null}}; the correct way to load a class with a possibly-null CL reference is to use {{Class.forName(name, intitialize, loader)}}.
> 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, 8 months