[JBoss JIRA] (WFLY-3778) Tests in Manualmode test suite fail occasionally
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3778?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3778:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1105003|https://bugzilla.redhat.com/show_bug.cgi?id=1105003] from NEW to POST
> Tests in Manualmode test suite fail occasionally
> ------------------------------------------------
>
> Key: WFLY-3778
> URL: https://issues.jboss.org/browse/WFLY-3778
> Project: WildFly
> Issue Type: Bug
> Components: Remoting, Test Suite
> Affects Versions: 9.0.0.Alpha1
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.7.0_67.
> Reporter: Frank Langelage
> Assignee: David Lloyd
> Attachments: org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase-output.txt, org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.txt, TEST-org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.xml
>
>
> I always see failures in one or few test of manualmode test suite on this platform. I not remember to have seen them on Windows 7.
> But I saw a very similar failure today on Linux first time for PR 6638.
> See https://github.com/wildfly/wildfly/pull/6638.
> Last failure on my machine:
> {noformat}
> Running org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.186 sec <<< FAILURE! - in org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase
> testRightVaultPassword(org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase) Time elapsed: 6.23 sec <<< FAILURE!
> java.lang.AssertionError: Password should be right and authentication successful
> Expected: a string containing "\"outcome\" => \"success\""
> but: was "0: INFO [org.jboss.modules] JBoss Modules version 1.3.4.Final
> INFO [org.jboss.security] PBOX000361: Default Security Vault Implementation Initialized and Ready
> INFO [org.xnio] XNIO version 3.3.0.Beta1
> INFO [org.xnio.nio] XNIO NIO Implementation Version 3.3.0.Beta1
> INFO [org.jboss.remoting] JBoss Remoting version 4.0.3.Final
> "
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.jboss.as.test.manualmode.management.cli.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:158)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (JGRP-1907) ENCRYPT: asymmetric encryption fails on merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1907?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1907:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1187193|https://bugzilla.redhat.com/show_bug.cgi?id=1187193] from VERIFIED to CLOSED
> ENCRYPT: asymmetric encryption fails on merge
> ---------------------------------------------
>
> Key: JGRP-1907
> URL: https://issues.jboss.org/browse/JGRP-1907
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.2
>
> Attachments: encrypt.xml, EncryptKeyStore.xml
>
>
> {{ENCRYPT}} fails to communicate after a network split and subsequent merge with asymmetric encryption. This works with symmetric encryption.
> To reproduce:
> * Members A and B
> * Add {{<DISCARD use_gui="true"/>}} on top of {{UDP}}
> * Form cluster {{(A,B)}}
> * Create a network split: {{(A)}} and {{(B)}}
> * Remove the network split
> * Observe that with both symmetric and asymmetric encryption, the merge forms cluster {{(A,B)}}
> * However, with asymmetric encryption, {{ENCRYPT}} fails to process any messages and rejects all messages, whereas with symmetric encryption, this works.
> * Symmetric encryption: {{EncryptKeyStore.xml}}
> * Asymmetric encryption: {{encrypt.xml}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFCORE-619) HostControllerExecutionSupport.MultiStepOpExecutionSupport doesn't format nested composites correctly
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-619:
---------------------------------------
Summary: HostControllerExecutionSupport.MultiStepOpExecutionSupport doesn't format nested composites correctly
Key: WFCORE-619
URL: https://issues.jboss.org/browse/WFCORE-619
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Beta2
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.CR1
The getFormattedDomainResult isn't processing nested composites correctly. It takes the response for the top level step and passes it into the HostControllerExecutionSupport for that step. That's fine for the simple response variants of HostControllerExecutionSupport, which just return the passed in node. But it fails if the support for that step is in turn MultiStepOpExecutionSupport, as it is expecting a response node's 'result' child, not the outer response node itself.
Solution is to detect this, clone the outer response node, and pass it's 'result' child into the child MultiStepOpExecutionSupport, replacing the outer response node's 'result' with the return value.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (REMJMX-100) Switch the build to depend on Java 7 as minimum
by Darran Lofthouse (JIRA)
Darran Lofthouse created REMJMX-100:
---------------------------------------
Summary: Switch the build to depend on Java 7 as minimum
Key: REMJMX-100
URL: https://issues.jboss.org/browse/REMJMX-100
Project: Remoting JMX
Issue Type: Task
Components: Build
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 2.0.1.CR2
Dependencies we use already require Java 7 and we are going into an application server that uses Java 7 as a minimum so no longer a reason to keep our source compatible with Java 6.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-3821) standalone.sh --debug without port number not working
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-3821?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil resolved WFLY-3821.
-------------------------------
Fix Version/s: 9.0.0.CR1
Resolution: Cannot Reproduce Bug
Most recent version of WFCORE's standalone.sh works as expected:
./standalone.sh => no debug
./standalone.sh --debug => debug on default 8787
./standalone.sh --debug 9797 => debug on 9797
> standalone.sh --debug without port number not working
> -----------------------------------------------------
>
> Key: WFLY-3821
> URL: https://issues.jboss.org/browse/WFLY-3821
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 9.0.0.Alpha1
> Reporter: Cheng Fang
> Assignee: Jeff Mesnil
> Fix For: 9.0.0.CR1
>
>
> ./standalone.sh --debug does not work, while ./standalone.sh --debug 8787 works.
> Looks like the fix to WFLY-2261 is lost in later revisions of standalone.sh.
> After the wildfly-core split, ./core-feature-pack/src/main/resources/content/bin/standalone.sh does not contain those lines of fix for WFLY-2261
> This bug is the same as WFLY-2261, except on a later version of WildFly. To avoid confusing EAP issues, create a separate one.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month
[JBoss JIRA] (WFLY-4482) JVM crash when enabling hornetQ
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-4482:
---------------------------------
Summary: JVM crash when enabling hornetQ
Key: WFLY-4482
URL: https://issues.jboss.org/browse/WFLY-4482
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 8.1.0.Final
Environment: SLES10 32bit
Oracle JDK 7.0_71
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Priority: Minor
When I enable HornetQ on this wildfly instance on SLES10, while starting up the JVM crashes with a SIGFPE - probably while trying to load libHornetQAIO.
Disabling HornetQ starts Wildfly without a problem.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 1 month