[JBoss JIRA] (JGRP-2080) New Address which contains IP address and port
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2080 at 9/1/16 5:12 AM:
--------------------------------------------------------
We also need to look at whether local_addr is set correctly in ForkChannels.
UPDATE: yes, this is correct: local_addr is set on ForkChannel.connect()
was (Author: belaban):
We also need to look at whether local_addr is set correctly in ForkChannels
> New Address which contains IP address and port
> ----------------------------------------------
>
> Key: JGRP-2080
> URL: https://issues.jboss.org/browse/JGRP-2080
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1682) Missleading tab completion for edit-batch-line command
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1682?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1682:
----------------------------------------------
Yes, this problem has been fixed.
> Missleading tab completion for edit-batch-line command
> ------------------------------------------------------
>
> Key: WFCORE-1682
> URL: https://issues.jboss.org/browse/WFCORE-1682
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for edit-batch-list command suggest to use --line-number as a command option, but that is not how the command works.
> *command usage*
> {noformat}
> [standalone@localhost:9990 /] batch
> [standalone@localhost:9990 / #] :read-resource
> [standalone@localhost:9990 / #] list-batch
> #1 /:read-resource
> [standalone@localhost:9990 / #] edit-batch-line 1 :read-attribute(name=launch-type)
> #1 :read-attribute(name=launch-type)
> [standalone@localhost:9990 / #] list-batch
> #1 :read-attribute(name=launch-type)
> {noformat}
> *actual*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> [standalone@localhost:9990 / #] edit-batch-line --<TAB>
> --help --line-number
> [standalone@localhost:9990 / #] edit-batch-line --line-number=1 :read-attribute(name=launch-type)
> Failed to parse line number '--line-number=1': For input string: "--line-number=1"
> {noformat}
> {{--line-number}} shouldn't be offered by tab completion for the command.
> Misleading tab completion ends up with syntax error.
> *expected*
> {noformat}
> [standalone@localhost:9990 / #] edit-batch-line <TAB>
> --help
> {noformat}
> The issue is a regression against EAP 7.0.0 release.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFLY-3915) Dynamic configuration of outbound SSL connections
by Mayurapriyan Sivaraman (JIRA)
[ https://issues.jboss.org/browse/WFLY-3915?page=com.atlassian.jira.plugin.... ]
Mayurapriyan Sivaraman commented on WFLY-3915:
----------------------------------------------
I was exactly looking for this feature. Do anyone know of alternative configuration for this feature in jboss EAP ?
> Dynamic configuration of outbound SSL connections
> -------------------------------------------------
>
> Key: WFLY-3915
> URL: https://issues.jboss.org/browse/WFLY-3915
> Project: WildFly
> Issue Type: Feature Request
> Reporter: James Livingston
> Assignee: Jason Greene
>
> WebSphere has a feature called "Dynamic outbound SSL configuration" (http://www-01.ibm.com/support/knowledgecenter/SSCKBL_8.5.5/com.ibm.websph...), which allows the configuration of SSL parameters for connections which are not opened directly by the container.
> That can be useful for configuring the SSL usage of components such as resource adapters, JDBC drivers, and application-packaged web service libraries. For example the truststore/keystore could be configured different for all requests to the database host, so that the global javax.net.ssl settings to not need to be modified if the driver does not itself provide a way to configure it.
> I believe that it is implemented by using javax.net.ssl.SSLContext.setDefault() to replace the standard socket factory. The socket factory could then look at the passed hostname/port, and potentially the calling application to configure the SSL socket appropriately before returning it to the caller.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-1708) ReconnectSyslogServerTestCase from wf-core fails intermittently
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1708?page=com.atlassian.jira.plugi... ]
Ondrej Lukas reopened WFCORE-1708:
----------------------------------
Still fails on Solaris. See JBEAP-5564 for details.
> ReconnectSyslogServerTestCase from wf-core fails intermittently
> ---------------------------------------------------------------
>
> Key: WFCORE-1708
> URL: https://issues.jboss.org/browse/WFCORE-1708
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 3.0.0.Alpha4
> Reporter: Ondrej Lukas
> Assignee: Ondrej Lukas
> Fix For: 3.0.0.Alpha5
>
>
> *Description of problem:*
> ReconnectSyslogServerTestCase from wf-core fails intermittently.
> *How reproducible:*
> 2%
> *Actual results:*
> Stacktrace:
> {noformat}
> java.lang.AssertionError: No message was logged into the TCP syslog after second syslog server restart
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.jboss.as.test.manualmode.logging.ReconnectSyslogServerTestCase.testReconnectSyslogServer(ReconnectSyslogServerTestCase.java:118)
> {noformat}
> Standard Output:
> {noformat}
> 10:59:13,639 INFO [org.wildfly.core.testrunner.Server] (main) Starting container with: /qa/tools/opt/x86_64/jdk1.8.0_91/jre/bin/java -D[Standalone] -javaagent:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/eap-local-maven-repository/org/jboss/byteman/byteman/3.0.3/byteman-3.0.3.jar=port:9091,boot:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/eap-local-maven-repository/org/jboss/byteman/byteman/3.0.3/byteman-3.0.3.jar,sys:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/shared/target/wildfly-core-testsuite-shared-3.0.0.Alpha4-redhat-1.jar -Dorg.jboss.byteman.transform.all -Dorg.jboss.byteman.verbose=true -Dmaven.repo.local=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/eap-local-maven-repository -Xmx512m -XX:MaxMetaspaceSize=256m -Djboss.dist=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv6Addresses=false -server -Dts.timeout.factor=100 -Djbossas.ts.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode -ea -Dorg.jboss.boot.log.file=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/log/server.log -Dlogging.configuration=file:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/configuration/logging.properties -jar /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/jboss-modules.jar -mp /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/modules org.jboss.as.standalone -Djboss.home.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core -Djboss.server.base.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone -Djboss.server.log.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/log -Djboss.server.config.dir=/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/configuration -c=standalone.xml -bmanagement=10.16.180.146 -Djboss.http.port=8080 -Djboss.bind.address=10.16.180.146
> 10:59:13,849 INFO [org.xnio] (main) XNIO version 3.4.0.Beta2
> 10:59:13,950 INFO [org.xnio.nio] (main) XNIO NIO Implementation Version 3.4.0.Beta2
> TransformListener() : accepting requests on localhost:9091
> 10:59:14,238 INFO [org.jboss.remoting] (main) JBoss Remoting version 4.0.21.Final-redhat-1
> &#27;[0m10:59:15,448 INFO [org.jboss.modules] (main) JBoss Modules version 1.5.2.Final-redhat-1
> &#27;[0m&#27;[0m10:59:16,071 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final-redhat-1
> &#27;[0m&#27;[0m10:59:16,385 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0049: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" starting
> &#27;[0m&#27;[0m10:59:17,878 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0039: Creating http management service using socket-binding (management-http)
> &#27;[0m&#27;[0m10:59:17,983 INFO [org.xnio] (MSC service thread 1-2) XNIO version 3.4.0.Beta2
> &#27;[0m&#27;[0m10:59:18,004 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.4.0.Beta2
> &#27;[0m&#27;[0m10:59:18,144 INFO [org.jboss.as.patching] (MSC service thread 1-1) WFLYPAT0050: WildFly cumulative patch ID is: base, one-off patches include: none
> &#27;[0m&#27;[0m10:59:18,180 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 4.0.21.Final-redhat-1
> &#27;[0m&#27;[33m10:59:18,208 WARN [org.jboss.as.domain.management.security] (MSC service thread 1-1) WFLYDM0111: Keystore /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/configuration/application.keystore not found, it will be auto generated on first use with a self signed certificate for host localhost
> &#27;[0m&#27;[33m10:59:18,352 WARN [org.jboss.as.domain.http.api.undertow] (MSC service thread 1-1) WFLYDMHTTP0003: Unable to load console module for slot main, disabling console
> &#27;[0m&#27;[0m10:59:18,924 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://10.16.180.146:9990/management
> &#27;[0m&#27;[0m10:59:18,925 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://10.16.180.146:9990
> &#27;[0m&#27;[0m10:59:18,925 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" started in 4551ms - Started 59 of 62 services (20 services are lazy, passive or on-demand)
> &#27;[0m&#27;[0m10:59:19,841 INFO [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0001: Content added at location /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/data/content/b6/795345f1851ba393f4f56dcd0e08328efcc090/content
> &#27;[0m&#27;[0m10:59:19,880 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "logging-test.jar" (runtime-name: "logging-test.jar")
> &#27;[0m&#27;[0m10:59:20,076 INFO [org.wildfly.test.undertow.UndertowService] (MSC service thread 1-2) Started Undertow on 10.16.180.146:8080
> &#27;[0m&#27;[0m10:59:20,131 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0010: Deployed "logging-test.jar" (runtime-name : "logging-test.jar")
> &#27;[0m&#27;[0m10:59:27,185 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage
> &#27;[0m10:59:27,739 WARN [org.jboss.as.test.syslogserver.UDPSyslogServer] (SyslogServer: udp) SocketException occurred: java.net.SocketException: Socket closed
> at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
> at java.net.DatagramSocket.receive(DatagramSocket.java:812)
> at org.jboss.as.test.syslogserver.UDPSyslogServer.run(UDPSyslogServer.java:62)
> at java.lang.Thread.run(Thread.java:745)
> 10:59:28,239 ERROR [org.jboss.as.test.syslogserver.TCPSyslogServer] (SyslogServer: tcp) IOException occurred.: java.net.SocketException: Socket closed
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
> at java.net.ServerSocket.implAccept(ServerSocket.java:545)
> at java.net.ServerSocket.accept(ServerSocket.java:513)
> at org.jboss.as.test.syslogserver.TCPSyslogServer.run(TCPSyslogServer.java:55)
> at java.lang.Thread.run(Thread.java:745)
> 10:59:28,241 WARN [org.jboss.as.test.syslogserver.TCPSyslogSocketHandler] (Thread-6) IOException occurred: java.net.SocketException: Socket closed
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> at org.jboss.as.test.syslogserver.TCPSyslogSocketHandler.run(TCPSyslogSocketHandler.java:73)
> at java.lang.Thread.run(Thread.java:745)
> &#27;[0m10:59:28,255 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage
> &#27;[0mLogManager error of type WRITE_FAILURE: Error writing to TCP stream
> java.net.SocketException: Broken pipe
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182)
> at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:173)
> at org.jboss.logmanager.handlers.SyslogHandler.sendMessage(SyslogHandler.java:579)
> at org.jboss.logmanager.handlers.SyslogHandler.doPublish(SyslogHandler.java:540)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logmanager.Logger.log(Logger.java:814)
> at org.jboss.logging.JBossLogManagerLogger.doLog(JBossLogManagerLogger.java:42)
> at org.jboss.logging.Logger.info(Logger.java:955)
> at org.jboss.as.test.manualmode.logging.LoggingServiceActivator$1.handleRequest(LoggingServiceActivator.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:57)
> 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:565)
> &#27;[0m10:59:28,263 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-2) someLogMessage
> &#27;[0m&#27;[0m10:59:36,291 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage
> &#27;[0m10:59:36,794 WARN [org.jboss.as.test.syslogserver.UDPSyslogServer] (SyslogServer: udp) SocketException occurred: java.net.SocketException: Socket closed
> at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
> at java.net.DatagramSocket.receive(DatagramSocket.java:812)
> at org.jboss.as.test.syslogserver.UDPSyslogServer.run(UDPSyslogServer.java:62)
> at java.lang.Thread.run(Thread.java:745)
> 10:59:37,295 ERROR [org.jboss.as.test.syslogserver.TCPSyslogServer] (SyslogServer: tcp) IOException occurred.: java.net.SocketException: Socket closed
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
> at java.net.ServerSocket.implAccept(ServerSocket.java:545)
> at java.net.ServerSocket.accept(ServerSocket.java:513)
> at org.jboss.as.test.syslogserver.TCPSyslogServer.run(TCPSyslogServer.java:55)
> at java.lang.Thread.run(Thread.java:745)
> &#27;[0m10:59:37,298 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-2) someLogMessage
> &#27;[0m&#27;[0m10:59:37,310 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-1) someLogMessage
> &#27;[0m10:59:37,313 ERROR [org.jboss.as.test.syslogserver.Rfc5424SyslogEvent] (Thread-9) Can't parse priority
> 10:59:37,313 WARN [org.jboss.as.test.syslogserver.TCPSyslogSocketHandler] (Thread-9) IOException occurred: java.net.SocketException: Socket closed
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> at org.jboss.as.test.syslogserver.TCPSyslogSocketHandler.run(TCPSyslogSocketHandler.java:73)
> at java.lang.Thread.run(Thread.java:745)
> &#27;[0m10:59:45,316 INFO [org.jboss.as.test.manualmode.logging.LoggingServiceActivator] (XNIO-1 I/O-2) someLogMessage
> &#27;[0m10:59:50,955 WARN [org.jboss.as.test.syslogserver.UDPSyslogServer] (SyslogServer: udp) SocketException occurred: java.net.SocketException: Socket closed
> at java.net.PlainDatagramSocketImpl.receive0(Native Method)
> at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
> at java.net.DatagramSocket.receive(DatagramSocket.java:812)
> at org.jboss.as.test.syslogserver.UDPSyslogServer.run(UDPSyslogServer.java:62)
> at java.lang.Thread.run(Thread.java:745)
> 10:59:51,456 ERROR [org.jboss.as.test.syslogserver.TCPSyslogServer] (SyslogServer: tcp) IOException occurred.: java.net.SocketException: Socket closed
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
> at java.net.ServerSocket.implAccept(ServerSocket.java:545)
> at java.net.ServerSocket.accept(ServerSocket.java:513)
> at org.jboss.as.test.syslogserver.TCPSyslogServer.run(TCPSyslogServer.java:55)
> at java.lang.Thread.run(Thread.java:745)
> &#27;[0m10:59:51,517 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) WFLYSRV0028: Stopped deployment logging-test.jar (runtime-name: logging-test.jar) in 17ms
> &#27;[0m&#27;[33m10:59:51,525 WARN [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0357: Notification of type deployment-undeployed is not described for the resource at the address []
> &#27;[0m&#27;[0m10:59:51,527 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-core/0728bde1/testsuite/manualmode/target/wildfly-core/standalone/data/content/b6/795345f1851ba393f4f56dcd0e08328efcc090/content
> &#27;[0m&#27;[0m10:59:51,528 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "logging-test.jar" (runtime-name: "logging-test.jar")
> &#27;[0m&#27;[0m10:59:51,549 INFO [org.jboss.as.server] (management-handler-thread - 2) WFLYSRV0236: Suspending server with no timeout.
> &#27;[0m&#27;[0m10:59:51,552 INFO [org.jboss.as.server] (Management Triggered Shutdown) WFLYSRV0241: Shutting down in response to management operation 'shutdown'
> &#27;[0m&#27;[0m10:59:51,704 INFO [org.jboss.as] (MSC service thread 1-2) WFLYSRV0050: WildFly Core 3.0.0.Alpha4-redhat-1 "Kenny" stopped in 97ms
> &#27;[0m
> {noformat}
> Standard Error Output:
> {noformat}
> Exception in thread "Thread-13" java.lang.NullPointerException
> at org.wildfly.core.testrunner.Server.lambda$stop$0(Server.java:184)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> Links to jenkins reports:
> * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
> * https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-as-testsuite-...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-91:
-----------------------------------
Fix Version/s: 3.0.0.Alpha7
(was: 3.0.0.Alpha6)
> Review use of Locale in toLowerCase() calls
> -------------------------------------------
>
> Key: WFCORE-91
> URL: https://issues.jboss.org/browse/WFCORE-91
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha7
>
>
> There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed:
> {code}
> $ git grep "toLowerCase()"
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress
> domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc
> domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor
> host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo
> host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase();
> server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + "
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow
> testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-13:
-----------------------------------
Fix Version/s: 3.0.0.Alpha7
(was: 3.0.0.Alpha6)
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
> Fix For: 3.0.0.Alpha7
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-363:
------------------------------------
Fix Version/s: 3.0.0.Alpha7
(was: 3.0.0.Alpha6)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha7
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-311:
------------------------------------
Fix Version/s: 3.0.0.Alpha7
(was: 3.0.0.Alpha6)
> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-311
> URL: https://issues.jboss.org/browse/WFCORE-311
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: RH EL 6.3 - JBoss EAP 6.2
> Reporter: Riccardo Benvenuti
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha7
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
> <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
> JAVA: /usr/java/jdk1.7.0_51/bin/java
> JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly
> <domain-controller>
> <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months
[JBoss JIRA] (WFCORE-301) Configuration of individual contexts for http management interface.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-301?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-301:
------------------------------------
Fix Version/s: 3.0.0.Alpha7
(was: 3.0.0.Alpha6)
> Configuration of individual contexts for http management interface.
> -------------------------------------------------------------------
>
> Key: WFCORE-301
> URL: https://issues.jboss.org/browse/WFCORE-301
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Labels: affects_elytron
> Fix For: 3.0.0.Alpha7
>
>
> At the moment all management requests are handled over the '/management' context, we also have a '/console' context to serve up the files for the admin console.
> The '/management' context is secured using standard HTTP mechanisms, this decision was taken so that clients could be written in different languages and all they would need to know is how to use standard authentication mechanisms. Due to problems where web browsers could run malicious scripts cross origin resource sharing is completely disabled for this context.
> We need to start to open up the handling of cross origin requests for a couple of reasons: -
> - Enabling Keycloak SSO support.
> - Alternative console distribution options
> The '/management' context is going to be retained as-is for legacy clients, possibly even switched off by default.
> A new context can then be added using non-browser based authentication, this could be SSO Keycloak or could be a form of Digest authentication where the response is handled by the console and not the web browser - either way as the browser is bypassed it is no longer at risk of sending malicious cross origin requests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 3 months