April 2015 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-4169) Wildfly doesn't fail on deployment EJB with CDI @Transactional

by Carlo de Wolf (JIRA)

[ https://issues.jboss.org/browse/WFLY-4169?page=com.atlassian.jira.plugin.... ] Carlo de Wolf commented on WFLY-4169: ------------------------------------- Technically speaking using Transactional interceptors on EJBs *is* allowed. See https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2013-0... The truth is that nobody wanted to figure out the impact of having JTA interceptors and CMT interceptors in place. So you could for example use BMT and JTA interceptors. I think this may need to become a configuration option. > Wildfly doesn't fail on deployment EJB with CDI @Transactional > -------------------------------------------------------------- > > Key: WFLY-4169 > URL: https://issues.jboss.org/browse/WFLY-4169 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.2.0.Final > Reporter: Kamil Żbikowski > > When javax.transaction.@Transactional CDI is put on EJB application is able to be correctly deployed on the server. According to JSR345 it should not be possible. ??It is illegal to associate JTA transactional interceptors \[8\] with Enterprise JavaBeans. The EJB Container should fail deployment of such applications.?? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (REMJMX-99) Release Remoting JMX 2.0.1.CR2

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-99: -------------------------------------- Summary: Release Remoting JMX 2.0.1.CR2 Key: REMJMX-99 URL: https://issues.jboss.org/browse/REMJMX-99 Project: Remoting JMX Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 2.0.1.CR2 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFCORE-618) Upgrade to Remoting JMX 2.0.1.CR2

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-618?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-618: ------------------------------------ Description: This update will be pulling in predominantly community reported issues. > Upgrade to Remoting JMX 2.0.1.CR2 > --------------------------------- > > Key: WFCORE-618 > URL: https://issues.jboss.org/browse/WFCORE-618 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.CR1 > > > This update will be pulling in predominantly community reported issues. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-618) Upgrade to Remoting JMX 2.0.1.CR2

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-618: --------------------------------------- Summary: Upgrade to Remoting JMX 2.0.1.CR2 Key: WFCORE-618 URL: https://issues.jboss.org/browse/WFCORE-618 Project: WildFly Core Issue Type: Component Upgrade Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.CR1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2015