[JBoss JIRA] (JGRP-1947) JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1947?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1947:
---------------------------
Fix Version/s: 3.6.5
> JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
> ----------------------------------------------------------------------
>
> Key: JGRP-1947
> URL: https://issues.jboss.org/browse/JGRP-1947
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.6
> Environment: Java 7u80 x32
> Tomcat 7.0.62
> HA-JDBC 3.0.4-SNAPSHOT + JGroups 3.4.6
> nmap 5.5.1
> Reporter: Justin Cranford
> Assignee: Bela Ban
> Fix For: 3.6.5
>
>
> I am running a two node Tomcat cluster. Both JGroups and Hazelcast are used for different parts of application clustering - JGroups for HA-JDBC, and Hazelcast for application locks outside of HA-JDBC.
> Hazelcast is not relevant to JGroups, except I included the Hazelcast errors because they happen at the same time as the JGroups JGRP000006 errors. This gave me a hint of why I see JGRP000006, because the Hazelcast error is more specific about root cause.
> Basically if I run a nmap TCP Connect scan on my servers like so, this opens/closes empty TCP connections. JGroups reports these events as JGRP000006, whereas Hazelcast reports them as "java.io.IOException[Connection reset by peer]".
> I am wondering if JGroups can handle these nmap TCP Connect scans more gracefully, or even log a more descriptive error with the JGRP000006 error code.
> My Tomcat errors for both JGroups and Hazelcast
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.SocketAcceptor
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Accepting socket connection from /10.0.0.86:40527
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnectionManager
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] 5900 accepted socket connection from /10.0.0.86:40527
> Jul 31, 2015 12:27:52 AM org.jgroups.logging.JDKLogImpl warn
> WARNING: JGRP000006: failed accepting connection from peer
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(Unknown Source)
> at java.net.SocketInputStream.read(Unknown Source)
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read1(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at java.io.DataInputStream.readFully(Unknown Source)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.readPeerAddress(TCPConnectionMap.java:494)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:376)
> at org.jgroups.blocks.TCPConnectionMap$Acceptor.handleAccept(TCPConnectionMap.java:298)
> at org.jgroups.blocks.TCPConnectionMap$Acceptor.run(TCPConnectionMap.java:282)
> at java.lang.Thread.run(Unknown Source)
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnection
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Connection [/10.0.0.86:40527] lost. Reason: java.io.IOException[Connection reset by peer]
> My nmap scan which triggers the JGRP000006 errors:
> root@myserver:~$ nmap -n -T4 -sT -PN --max-scan-delay 0ms --min-rate 1000000 --max-retries 0 -p 443,3306,5900,7900,7901 10.0.0.85
> Starting Nmap 5.51 ( http://nmap.org ) at 2015-07-31 01:33 UTC
> Cannot find nmap-payloads. UDP payloads are disabled.
> Nmap scan report for 10.0.0.85
> Host is up (0.00035s latency).
> PORT STATE SERVICE
> 443/tcp open https
> 3306/tcp open mysql
> 5900/tcp open vnc
> 7900/tcp open mevent
> 7901/tcp open unknown
> Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (WFLY-4790) Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4790?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4790.
----------------------------------
Resolution: Done
Should be fixed in Undertow 1.3.0.Beta4
> Getting DirectBuffer OOM when sending fragmented binary message to websocket endpoint
> -------------------------------------------------------------------------------------
>
> Key: WFLY-4790
> URL: https://issues.jboss.org/browse/WFLY-4790
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha3
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.Beta1
>
>
> When sending fragmented binary message (message with message payload of length 4 * 2**20 (4M). Sent out in fragments of 64). The server throws {{java.lang.OutOfMemoryError: Direct buffer memory}} [1]
> The memory for direct buffer by default depends on the size set by -Xmx, which is in EAP 7.0.0.DR4 by default set to -Xmx512m. Increasing it just increases the time before the limit is hit (it is enough to send those messages multiple times to hit the limit again).
> I believe the issue is similar to the one for EAP 6.4: [https://bugzilla.redhat.com/show_bug.cgi?id=1223708]
> [1]
> {noformat}
> 15:10:55,463 ERROR [org.xnio.listener] (default I/O-1) XNIO001007: A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory
> at java.nio.Bits.reserveMemory(Bits.java:658)
> at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
> at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57)
> at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55)
> at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:143)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:106)
> at io.undertow.websockets.core.BufferedBinaryMessage$1.handleEvent(BufferedBinaryMessage.java:97)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel$1.run(AbstractFramedStreamSourceChannel.java:264)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:560)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:462)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (DROOLS-866) Drools decision table with contains operator in a conditional group not working
by lucio piccoli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-866?page=com.atlassian.jira.plugin... ]
lucio piccoli updated DROOLS-866:
---------------------------------
Attachment: FeePricing-grouping-error.xls
PricingRuleGroupingExample.java
attached are the decision table and sample code that illustrates bug.
> Drools decision table with contains operator in a conditional group not working
> -------------------------------------------------------------------------------
>
> Key: DROOLS-866
> URL: https://issues.jboss.org/browse/DROOLS-866
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 6.2.0.Final
> Environment: Windows 7
> Reporter: lucio piccoli
> Assignee: Mario Fusco
> Attachments: FeePricing-grouping-error.xls, PricingRuleGroupingExample.java
>
>
> I cannot get the Decision Table to using grouping in the expression.
> Decision Table
> ------------------------------------
> <row 10> CONDITION
> <row 12> classList $param
> expressions are in each row.
> <row 43> (contains('AAA') || contains('BBB') ) && contains('CCC') <--fails to compile
> <row 44> (contains('AAA') || contains('BBB')
> <row 45> (contains('AA') || contains('BB') || contains('CCC') || contains('DDD')
> where the fact classList is
> List<String> classList = {'AAA', 'BB'.....}
> the rule43 is meant to fire if the list contains either 'AAA' OR 'BBB' AND 'CCC'
> however the decision table parser is failing with exception for rule 43
> [Error: Missing left node]
> [Near : {... classList (contains("AAA") || contains("CCC")) ....}]
> i have a similar rule working fine for other rows
> <row 42> contains('AAA') || contains('BBB') || contains('CCC')
> there seems to be something strange with using the contains operator in a group condition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (DROOLS-866) Drools decision table with contains operator in a conditional group not working
by lucio piccoli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-866?page=com.atlassian.jira.plugin... ]
lucio piccoli updated DROOLS-866:
---------------------------------
Steps to Reproduce:
attached decision table with grouping conditions that causes compilation error
was:
create a decision table with grouping conditions in each row.
i have example decsion table but dont know how to upload.
> Drools decision table with contains operator in a conditional group not working
> -------------------------------------------------------------------------------
>
> Key: DROOLS-866
> URL: https://issues.jboss.org/browse/DROOLS-866
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 6.2.0.Final
> Environment: Windows 7
> Reporter: lucio piccoli
> Assignee: Mario Fusco
> Attachments: FeePricing-grouping-error.xls, PricingRuleGroupingExample.java
>
>
> I cannot get the Decision Table to using grouping in the expression.
> Decision Table
> ------------------------------------
> <row 10> CONDITION
> <row 12> classList $param
> expressions are in each row.
> <row 43> (contains('AAA') || contains('BBB') ) && contains('CCC') <--fails to compile
> <row 44> (contains('AAA') || contains('BBB')
> <row 45> (contains('AA') || contains('BB') || contains('CCC') || contains('DDD')
> where the fact classList is
> List<String> classList = {'AAA', 'BB'.....}
> the rule43 is meant to fire if the list contains either 'AAA' OR 'BBB' AND 'CCC'
> however the decision table parser is failing with exception for rule 43
> [Error: Missing left node]
> [Near : {... classList (contains("AAA") || contains("CCC")) ....}]
> i have a similar rule working fine for other rows
> <row 42> contains('AAA') || contains('BBB') || contains('CCC')
> there seems to be something strange with using the contains operator in a group condition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (DROOLS-866) Drools decision table with contains operator in a conditional group not working
by lucio piccoli (JIRA)
lucio piccoli created DROOLS-866:
------------------------------------
Summary: Drools decision table with contains operator in a conditional group not working
Key: DROOLS-866
URL: https://issues.jboss.org/browse/DROOLS-866
Project: Drools
Issue Type: Bug
Components: decision tables
Affects Versions: 6.2.0.Final
Environment: Windows 7
Reporter: lucio piccoli
Assignee: Mario Fusco
I cannot get the Decision Table to using grouping in the expression.
Decision Table
------------------------------------
<row 10> CONDITION
<row 12> classList $param
expressions are in each row.
<row 43> (contains('AAA') || contains('BBB') ) && contains('CCC') <--fails to compile
<row 44> (contains('AAA') || contains('BBB')
<row 45> (contains('AA') || contains('BB') || contains('CCC') || contains('DDD')
where the fact classList is
List<String> classList = {'AAA', 'BB'.....}
the rule43 is meant to fire if the list contains either 'AAA' OR 'BBB' AND 'CCC'
however the decision table parser is failing with exception for rule 43
[Error: Missing left node]
[Near : {... classList (contains("AAA") || contains("CCC")) ....}]
i have a similar rule working fine for other rows
<row 42> contains('AAA') || contains('BBB') || contains('CCC')
there seems to be something strange with using the contains operator in a group condition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JGRP-1947) JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
by Justin Cranford (JIRA)
[ https://issues.jboss.org/browse/JGRP-1947?page=com.atlassian.jira.plugin.... ]
Justin Cranford updated JGRP-1947:
----------------------------------
Workaround Description: Use nmap TCP SYN scanning. Half-open scanning only reaches the TCP layer of the TCP/IP stack, whereas TCP Connection scanning reaches the application layer (ex: JGroups). Unfortunately SYN scanning requires root privileges, so this workaround is not always available. (was: Use nmap TCP SYN scanning. Half-open scanning open reaches the TCP layer of the TCP/IP stack, whereas TCP Connection scanning reaches the application layer (ex: JGroups). Unfortunately SYN scanning requires root privileges, so this workaround is not always available.)
> JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
> ----------------------------------------------------------------------
>
> Key: JGRP-1947
> URL: https://issues.jboss.org/browse/JGRP-1947
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4.6
> Environment: Java 7u80 x32
> Tomcat 7.0.62
> HA-JDBC 3.0.4-SNAPSHOT + JGroups 3.4.6
> nmap 5.5.1
> Reporter: Justin Cranford
> Assignee: Bela Ban
>
> I am running a two node Tomcat cluster. Both JGroups and Hazelcast are used for different parts of application clustering - JGroups for HA-JDBC, and Hazelcast for application locks outside of HA-JDBC.
> Hazelcast is not relevant to JGroups, except I included the Hazelcast errors because they happen at the same time as the JGroups JGRP000006 errors. This gave me a hint of why I see JGRP000006, because the Hazelcast error is more specific about root cause.
> Basically if I run a nmap TCP Connect scan on my servers like so, this opens/closes empty TCP connections. JGroups reports these events as JGRP000006, whereas Hazelcast reports them as "java.io.IOException[Connection reset by peer]".
> I am wondering if JGroups can handle these nmap TCP Connect scans more gracefully, or even log a more descriptive error with the JGRP000006 error code.
> My Tomcat errors for both JGroups and Hazelcast
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.SocketAcceptor
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Accepting socket connection from /10.0.0.86:40527
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnectionManager
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] 5900 accepted socket connection from /10.0.0.86:40527
> Jul 31, 2015 12:27:52 AM org.jgroups.logging.JDKLogImpl warn
> WARNING: JGRP000006: failed accepting connection from peer
> java.net.SocketException: Connection reset
> at java.net.SocketInputStream.read(Unknown Source)
> at java.net.SocketInputStream.read(Unknown Source)
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read1(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at java.io.DataInputStream.readFully(Unknown Source)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.readPeerAddress(TCPConnectionMap.java:494)
> at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:376)
> at org.jgroups.blocks.TCPConnectionMap$Acceptor.handleAccept(TCPConnectionMap.java:298)
> at org.jgroups.blocks.TCPConnectionMap$Acceptor.run(TCPConnectionMap.java:282)
> at java.lang.Thread.run(Unknown Source)
> Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnection
> INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Connection [/10.0.0.86:40527] lost. Reason: java.io.IOException[Connection reset by peer]
> My nmap scan which triggers the JGRP000006 errors:
> root@myserver:~$ nmap -n -T4 -sT -PN --max-scan-delay 0ms --min-rate 1000000 --max-retries 0 -p 443,3306,5900,7900,7901 10.0.0.85
> Starting Nmap 5.51 ( http://nmap.org ) at 2015-07-31 01:33 UTC
> Cannot find nmap-payloads. UDP payloads are disabled.
> Nmap scan report for 10.0.0.85
> Host is up (0.00035s latency).
> PORT STATE SERVICE
> 443/tcp open https
> 3306/tcp open mysql
> 5900/tcp open vnc
> 7900/tcp open mevent
> 7901/tcp open unknown
> Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (JGRP-1947) JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
by Justin Cranford (JIRA)
Justin Cranford created JGRP-1947:
-------------------------------------
Summary: JGRP000006 errors triggered by nmap TCP Connect scanning JGroups ports
Key: JGRP-1947
URL: https://issues.jboss.org/browse/JGRP-1947
Project: JGroups
Issue Type: Bug
Affects Versions: 3.4.6
Environment: Java 7u80 x32
Tomcat 7.0.62
HA-JDBC 3.0.4-SNAPSHOT + JGroups 3.4.6
nmap 5.5.1
Reporter: Justin Cranford
Assignee: Bela Ban
I am running a two node Tomcat cluster. Both JGroups and Hazelcast are used for different parts of application clustering - JGroups for HA-JDBC, and Hazelcast for application locks outside of HA-JDBC.
Hazelcast is not relevant to JGroups, except I included the Hazelcast errors because they happen at the same time as the JGroups JGRP000006 errors. This gave me a hint of why I see JGRP000006, because the Hazelcast error is more specific about root cause.
Basically if I run a nmap TCP Connect scan on my servers like so, this opens/closes empty TCP connections. JGroups reports these events as JGRP000006, whereas Hazelcast reports them as "java.io.IOException[Connection reset by peer]".
I am wondering if JGroups can handle these nmap TCP Connect scans more gracefully, or even log a more descriptive error with the JGRP000006 error code.
My Tomcat errors for both JGroups and Hazelcast
Jul 31, 2015 12:27:52 AM com.hazelcast.nio.SocketAcceptor
INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Accepting socket connection from /10.0.0.86:40527
Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnectionManager
INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] 5900 accepted socket connection from /10.0.0.86:40527
Jul 31, 2015 12:27:52 AM org.jgroups.logging.JDKLogImpl warn
WARNING: JGRP000006: failed accepting connection from peer
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read1(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
at java.io.DataInputStream.readFully(Unknown Source)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.readPeerAddress(TCPConnectionMap.java:494)
at org.jgroups.blocks.TCPConnectionMap$TCPConnection.<init>(TCPConnectionMap.java:376)
at org.jgroups.blocks.TCPConnectionMap$Acceptor.handleAccept(TCPConnectionMap.java:298)
at org.jgroups.blocks.TCPConnectionMap$Acceptor.run(TCPConnectionMap.java:282)
at java.lang.Thread.run(Unknown Source)
Jul 31, 2015 12:27:52 AM com.hazelcast.nio.TcpIpConnection
INFO: [10.0.0.85]:5900 [ClusterManager] [3.2.4] Connection [/10.0.0.86:40527] lost. Reason: java.io.IOException[Connection reset by peer]
My nmap scan which triggers the JGRP000006 errors:
root@myserver:~$ nmap -n -T4 -sT -PN --max-scan-delay 0ms --min-rate 1000000 --max-retries 0 -p 443,3306,5900,7900,7901 10.0.0.85
Starting Nmap 5.51 ( http://nmap.org ) at 2015-07-31 01:33 UTC
Cannot find nmap-payloads. UDP payloads are disabled.
Nmap scan report for 10.0.0.85
Host is up (0.00035s latency).
PORT STATE SERVICE
443/tcp open https
3306/tcp open mysql
5900/tcp open vnc
7900/tcp open mevent
7901/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (WFCORE-841) Patching module testsuite failure
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-841:
---------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 2.0.0.Alpha12)
> Patching module testsuite failure
> ---------------------------------
>
> Key: WFCORE-841
> URL: https://issues.jboss.org/browse/WFCORE-841
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Environment: $ java -version
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> OS X Yosemite 10.10.4
> Reporter: Brian Stansberry
> Assignee: Alexey Loubyansky
> Fix For: 2.0.0.Beta1
>
>
> When running the core build locally , the 'patching' module testsuite fails:
> {code}
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> objc[58076]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
> Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in org.jboss.as.patching.cli.ContentConflictsUnitTestCase
> Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
> Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<< FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
> testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase) Time elapsed: 0.044 sec <<< FAILURE!
> java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch 1, Identity name=product, Identity version=version, Patch ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
> at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
> at org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
> {code}
> If I clean and run the test by itself, it passes. It also passes on the CI jobs on brontes, but the log shows the tests excecute in a different order.
> Given all that, my expectation is that one of the two tests that run locally before the failing one is leaving some sort of mess behind. I've found that @Ignoring org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will send up a PR that does that as a workaround.
> The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master since then. One is an undertow upgrade, so it's almost certain the problem was introduced with the other: https://github.com/wildfly/wildfly-core/pull/904
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months
[JBoss JIRA] (WFCORE-840) Improve API on AttributeDefinitions where a capability is referenced.
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-840?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-840:
---------------------------------
Fix Version/s: 2.0.0.Beta1
(was: 2.0.0.Alpha12)
> Improve API on AttributeDefinitions where a capability is referenced.
> ---------------------------------------------------------------------
>
> Key: WFCORE-840
> URL: https://issues.jboss.org/browse/WFCORE-840
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha11
> Reporter: Darran Lofthouse
> Assignee: Tomaz Cerar
> Fix For: 2.0.0.Beta1
>
>
> Take the following method call defining an attribute: -
> {code}
> .setCapabilityReference(PROVIDERS_CAPABILITY, SASL_SERVER_FACTORY_CAPABILITY, true)
> {code}
> This definition says this attribute references something which provides the PROVIDERS_CAPABILITY.
> However it also states that the resource that contains this attributes provides the SASL_SERVER_FACTORY_CAPABILITY.
> Really what the resource provides is not directly related to this attribute definition.
> The following pull request has already improved on registering in advance what capability a resource can provide: -
> https://github.com/wildfly/wildfly-core/pull/909
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 9 months