October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-3872: --------------------------------------- Thanks Stuart, please link the jira or github commit here once available :) > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Alessio Soldano > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1682) ugly style allowing to start multiple servers refer to the same server-config file

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFLY-1682?page=com.atlassian.jira.plugin.... ] Claudio Miranda commented on WFLY-1682: --------------------------------------- You have two options 1) use domain mode 2) use a copy of standalone.xml to start the 2nd server > ugly style allowing to start multiple servers refer to the same server-config file > ---------------------------------------------------------------------------------- > > Key: WFLY-1682 > URL: https://issues.jboss.org/browse/WFLY-1682 > Project: WildFly > Issue Type: Enhancement > Components: Server > Affects Versions: 8.0.0.Alpha2 > Reporter: Jay Wu > Assignee: Jason Greene > > {color:red} > WildFly allows to start multiple servers refer to the same server-config as following > {color} > {noformat} > standalone.bat -server-config=standalone.xml -Djboss.node.name=node1 > {noformat} > {noformat} > standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node2 > {noformat} > {noformat} > standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=200 -Djboss.node.name=node3 > {noformat} > {color:red} > the three nodes do not share the modification， but the later will overwrite the former in the standalone.xml. > {color} > {quote} > for example > (1) create datasource "ds4node1" to node1 which created above. > and ds4node1 is written into standalone.xml. > ↓ > (2) careate datasource "ds4node2" to node2 > and ds4node1 which was created in step(1) is deleted from standalone.xml, > ds4node2 is written into standalone.xml. > ↓ > (3) careate datasource "ds4node3" to node3 > and ds4node2 which was created in step(2) is deleted from standalone.xml, > ds4node3 is written into standalone.xml. > {quote} > {color:red} > after restarting the three nodes, the three nodes refers to standalone.xml, and share the last created datasource "ds4node3"。 > {color} > {color:red} > the above style may confuse users. > if it is a style flaw, is there any plan to improve it. > {color} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-1682) ugly style allowing to start multiple servers refer to the same server-config file

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFLY-1682?page=com.atlassian.jira.plugin.... ] Claudio Miranda edited comment on WFLY-1682 at 10/9/14 11:23 PM: ----------------------------------------------------------------- I think this is not a bug, just because wfly allows users to do so. you have two options 1) use domain mode 2) use a copy of standalone.xml to start the 2nd server was (Author: claudio4j): You have two options 1) use domain mode 2) use a copy of standalone.xml to start the 2nd server > ugly style allowing to start multiple servers refer to the same server-config file > ---------------------------------------------------------------------------------- > > Key: WFLY-1682 > URL: https://issues.jboss.org/browse/WFLY-1682 > Project: WildFly > Issue Type: Enhancement > Components: Server > Affects Versions: 8.0.0.Alpha2 > Reporter: Jay Wu > Assignee: Jason Greene > > {color:red} > WildFly allows to start multiple servers refer to the same server-config as following > {color} > {noformat} > standalone.bat -server-config=standalone.xml -Djboss.node.name=node1 > {noformat} > {noformat} > standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=100 -Djboss.node.name=node2 > {noformat} > {noformat} > standalone.bat -server-config=standalone.xml -Djboss.socket.binding.port-offset=200 -Djboss.node.name=node3 > {noformat} > {color:red} > the three nodes do not share the modification， but the later will overwrite the former in the standalone.xml. > {color} > {quote} > for example > (1) create datasource "ds4node1" to node1 which created above. > and ds4node1 is written into standalone.xml. > ↓ > (2) careate datasource "ds4node2" to node2 > and ds4node1 which was created in step(1) is deleted from standalone.xml, > ds4node2 is written into standalone.xml. > ↓ > (3) careate datasource "ds4node3" to node3 > and ds4node2 which was created in step(2) is deleted from standalone.xml, > ds4node3 is written into standalone.xml. > {quote} > {color:red} > after restarting the three nodes, the three nodes refers to standalone.xml, and share the last created datasource "ds4node3"。 > {color} > {color:red} > the above style may confuse users. > if it is a style flaw, is there any plan to improve it. > {color} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3901) Please add the "relative-to" attribute to access-log in undertow

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFLY-3901?page=com.atlassian.jira.plugin.... ] Claudio Miranda commented on WFLY-3901: --------------------------------------- Wildfly 9.0.0.Alpha2-SNAPSHOT works {code} <access-log pattern="[%t] %U %s %I %D" directory="${jboss.server.log.dir}" prefix="prefixo" suffix="sufixo" rotate="true"/> {code} > Please add the "relative-to" attribute to access-log in undertow > ---------------------------------------------------------------- > > Key: WFLY-3901 > URL: https://issues.jboss.org/browse/WFLY-3901 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Affects Versions: 8.1.0.Final > Reporter: Carlton Zachary > Assignee: Tomaz Cerar > > I have been trying to point the "directory" attribute value to a var ${custom.jboss.server.log.dir} to write the access.log to a non-default location, but this diesn't work in undertow. It does work in EAP 6.2 JBoss-web. The custom.jboss.server.log.dir is defined in the "<paths>" in the servers section of the host-slave.xml file. > In JBoss EAP 6.2 with jboss-web the access-log has the "relative-to" attribute, but this is not the case with access-log for undertow in WFLY 8.1. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3872) Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-3872?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-3872: -------------------------------------- I think this is an undertow issue, I have a potential fix upstream > Recurring failure of EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn > -------------------------------------------------------------------------------------------- > > Key: WFLY-3872 > URL: https://issues.jboss.org/browse/WFLY-3872 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 9.0.0.Alpha1 > Reporter: Brian Stansberry > Assignee: Alessio Soldano > > Since https://github.com/wildfly/wildfly/pull/6660 was submitted, EJBSignEncryptMultipleClientsTestCase.encryptedAndSignedRequestFromJohn is failing regularly. Not every time but very often. > Alessio, you mentioned seeing some error logging from XAResourceRecoveryImpl, but that's in the logs on successful runs as well, and occurs prior to the test as well. That's a period background task from the transaction manager trying to perform recovery of some previous transaction. I don't see why it would have any impact on this test. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFLY-3943) There is no testing of the messaging subsystem integration with the JGroups subsystem

by Yong Hao Gao (JIRA)

[ https://issues.jboss.org/browse/WFLY-3943?page=com.atlassian.jira.plugin.... ] Yong Hao Gao commented on WFLY-3943: ------------------------------------ Thanks Brian. > There is no testing of the messaging subsystem integration with the JGroups subsystem > ------------------------------------------------------------------------------------- > > Key: WFLY-3943 > URL: https://issues.jboss.org/browse/WFLY-3943 > Project: WildFly > Issue Type: Task > Components: JMS > Reporter: Brian Stansberry > Assignee: Jeff Mesnil > Priority: Critical > Attachments: standalone-full-ha.xml > > > HornetQServerAdd and HornetQServerService have integration with the JGroups subsystem in order to add a dependency on a ChannelFactory for use with broadcast and discovery groups. But it seems there is no testing of this integration. > At the time I filed this it was broken, due to WFLY-3944, since fixed. > This JIRA is about the fact lack of testing that would have caught the WFLY-3944 bug. Also, https://github.com/wildfly/wildfly/pull/6725 passed the testsuite with a code change that was binary incompatible with the version of HQ that was integrated at the time. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-159) Handlers can be created with the same name as an existing handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-159?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-159: ------------------------------------------------ James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1151256|https://bugzilla.redhat.com/show_bug.cgi?id=1151256] from ASSIGNED to POST > Handlers can be created with the same name as an existing handler > ----------------------------------------------------------------- > > Key: WFCORE-159 > URL: https://issues.jboss.org/browse/WFCORE-159 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > Handlers can be created with the same name as an existing handler. This was done to reconfigure differences in the logging subsystem XML and the logging.properties file. The problem is it will replace a handler during an {{ADD}} operation if the same name is used on another parent resource. > {code} > /subsystem=logging/async-handler=CONSOLE:add(queue-length=10,overflow-action=BLOCK) > {code} > This will replace the default console handler with the new one keeping the existing console-handler resource. The next boot also fails with no indication on the console. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-158) Handlers should not be allowed to be removed if they're assigned to another handler or logger

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-158?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on WFCORE-158: ------------------------------------------------ James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1007333|https://bugzilla.redhat.com/show_bug.cgi?id=1007333] from ASSIGNED to POST > Handlers should not be allowed to be removed if they're assigned to another handler or logger > --------------------------------------------------------------------------------------------- > > Key: WFCORE-158 > URL: https://issues.jboss.org/browse/WFCORE-158 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > Handlers can currently be removed even if the handler is assigned to a logger or another handler. This allows an invalid {{logging.properties}} file to be written and will fail to start the server on the next boot. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-159) Handlers can be created with the same name as an existing handler

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-159?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-159: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1151256 > Handlers can be created with the same name as an existing handler > ----------------------------------------------------------------- > > Key: WFCORE-159 > URL: https://issues.jboss.org/browse/WFCORE-159 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > Handlers can be created with the same name as an existing handler. This was done to reconfigure differences in the logging subsystem XML and the logging.properties file. The problem is it will replace a handler during an {{ADD}} operation if the same name is used on another parent resource. > {code} > /subsystem=logging/async-handler=CONSOLE:add(queue-length=10,overflow-action=BLOCK) > {code} > This will replace the default console handler with the new one keeping the existing console-handler resource. The next boot also fails with no indication on the console. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-159) Handlers can be created with the same name as an existing handler

by James Perkins (JIRA)

James Perkins created WFCORE-159: ------------------------------------ Summary: Handlers can be created with the same name as an existing handler Key: WFCORE-159 URL: https://issues.jboss.org/browse/WFCORE-159 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: James Perkins Assignee: James Perkins Handlers can be created with the same name as an existing handler. This was done to reconfigure differences in the logging subsystem XML and the logging.properties file. The problem is it will replace a handler during an {{ADD}} operation if the same name is used on another parent resource. {code} /subsystem=logging/async-handler=CONSOLE:add(queue-length=10,overflow-action=BLOCK) {code} This will replace the default console handler with the new one keeping the existing console-handler resource. The next boot also fails with no indication on the console. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2014