[JBoss JIRA] (JGRP-1796) Fix flush problem with integration of commons-logging output
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1796?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1796:
--------------------------------------
Fix Version/s: 3.3.6
3.5
> Fix flush problem with integration of commons-logging output
> ------------------------------------------------------------
>
> Key: JGRP-1796
> URL: https://issues.jboss.org/browse/JGRP-1796
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13, 3.3.6, 3.5
>
>
> The commons-logging output which appears in test case output files does not have line termination processed correctly. We end up with text like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member120666 [DEBUG] GMS: - A: installing view [A|0] [A]120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> This makes reading the logging output hard to read.
> We want it to look like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member
> 120666 [DEBUG] GMS: - A: installing view [A|0] [A]
> 120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> Th solution is to implement flush() as a method which simply appends a null string with CR/LF applied as well to the current collected sysout and syserr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1796) Fix flush problem with integration of commons-logging output
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1796?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-1796:
--------------------------------------
Description:
The commons-logging output which appears in test case output files does not have line termination processed correctly. We end up with text like this:
{noformat}
120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member120666 [DEBUG] GMS: - A: installing view [A|0] [A]120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
{noformat}
This makes reading the logging output hard to read.
We want it to look like this:
{noformat}
120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member
120666 [DEBUG] GMS: - A: installing view [A|0] [A]
120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
{noformat}
Th solution is to implement flush() as a method which simply appends a null string with CR/LF applied as well to the current collected sysout and syserr.
was:
The commons-logging output which appears in test case output files does not have line termination processed correctly. We end up with text like this:
{noformat}
{noformat}
This makes reading the logging output hard to read.
Th solution is to implement flush() as a method which simply appends a null string with CR/LF applied as well to the current collected sysout and syserr.
> Fix flush problem with integration of commons-logging output
> ------------------------------------------------------------
>
> Key: JGRP-1796
> URL: https://issues.jboss.org/browse/JGRP-1796
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13
>
>
> The commons-logging output which appears in test case output files does not have line termination processed correctly. We end up with text like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member120666 [DEBUG] GMS: - A: installing view [A|0] [A]120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> This makes reading the logging output hard to read.
> We want it to look like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member
> 120666 [DEBUG] GMS: - A: installing view [A|0] [A]
> 120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> Th solution is to implement flush() as a method which simply appends a null string with CR/LF applied as well to the current collected sysout and syserr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1796) Fix flush problem with integration of commons-logging output
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1796?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1796:
-------------------------------------------
I'm sure this was fixed in 2008 when I first implemented it!
> Fix flush problem with integration of commons-logging output
> ------------------------------------------------------------
>
> Key: JGRP-1796
> URL: https://issues.jboss.org/browse/JGRP-1796
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
> Fix For: 3.2.13
>
>
> The commons-logging output which appears in test case output files does not have line termination processed correctly. We end up with text like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member120666 [DEBUG] GMS: - A: installing view [A|0] [A]120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> This makes reading the logging output hard to read.
> We want it to look like this:
> {noformat}
> 120665 [TRACE] GMS: - A: no initial members discovered: creating group as first member
> 120666 [DEBUG] GMS: - A: installing view [A|0] [A]
> 120666 [DEBUG] GMS: - created group (first member). My view is [A|0], impl is org.jgroups.protocols.pbcast.CoordGmsImpl
> {noformat}
> Th solution is to implement flush() as a method which simply appends a null string with CR/LF applied as well to the current collected sysout and syserr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1796) Fix flush problem with integration of commons-logging output
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created JGRP-1796:
-----------------------------------------
Summary: Fix flush problem with integration of commons-logging output
Key: JGRP-1796
URL: https://issues.jboss.org/browse/JGRP-1796
Project: JGroups
Issue Type: Bug
Affects Versions: 3.2.13
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Priority: Minor
Fix For: 3.2.13
The commons-logging output which appears in test case output files does not have line termination processed correctly. We end up with text like this:
{noformat}
{noformat}
This makes reading the logging output hard to read.
Th solution is to implement flush() as a method which simply appends a null string with CR/LF applied as well to the current collected sysout and syserr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-3001) JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
by Thomas Frühbeck (JIRA)
Thomas Frühbeck created WFLY-3001:
-------------------------------------
Summary: JSF WindowId: NPE in Weld HTTP BeanStore inhibits application access
Key: WFLY-3001
URL: https://issues.jboss.org/browse/WFLY-3001
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: CDI / Weld, JSF
Affects Versions: 8.0.0.CR1
Reporter: Thomas Frühbeck
Assignee: Stuart Douglas
Web session has been established, after _very_ long time (>> session timeout) browser refresh, URL refresh leads to NPE in weld beanstore on access to SessionScoped deltaspike DefaultClientWindowConfig bean.
>From that point on the _only_ possibility to access the application is clean of session cookies.
Stacktrace:
2014-02-23 16:59:13,319 ERROR [io.undertow.request] (default task-36) Servlet request failed HttpServerExchange{ GET /mssms2/faces/csms/groupManagement.xhtml}: java.lang.NullPoi
nterException
at org.jboss.weld.context.beanstore.http.AbstractSessionBeanStore.getLockStore(AbstractSessionBeanStore.java:113) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
at org.jboss.weld.context.beanstore.AttributeBeanStore.lock(AttributeBeanStore.java:210) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:88) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
at org.jboss.weld.context.PassivatingContextWrapper$AbstractPassivatingContextWrapper.get(PassivatingContextWrapper.java:76) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:
53]
at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:98) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:78) [weld-core-impl-2.1.0.CR1.jar:2013-09-26 16:53]
at org.apache.deltaspike.jsf.spi.scope.window.DefaultClientWindowConfig$Proxy$_$$_WeldClientProxy.getClientWindowRenderMode(Unknown Source) [deltaspike-jsf-module-api-0.
6-SNAPSHOT.jar:0.6-SNAPSHOT]
at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow.getWindowId(DefaultClientWindow.java:119) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6-SNAPSHOT]
at org.apache.deltaspike.jsf.impl.scope.window.DefaultClientWindow$Proxy$_$$_WeldClientProxy.getWindowId(Unknown Source) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.6
-SNAPSHOT]
at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:78) [deltaspike-jsf-module-impl-0.6-SNAPSHOT.jar:0.
6-SNAPSHOT]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-3000) Incorrect 'Content-Type' response set after executing an erroneous command
by Christos Vasilakis (JIRA)
Christos Vasilakis created WFLY-3000:
----------------------------------------
Summary: Incorrect 'Content-Type' response set after executing an erroneous command
Key: WFLY-3000
URL: https://issues.jboss.org/browse/WFLY-3000
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Domain Management
Affects Versions: 8.0.0.Final
Reporter: Christos Vasilakis
Assignee: Brian Stansberry
The http management interface, upon error, returns an incorrect 'Content-Type' of
{noformat}
'Content-Type: text/plain; charset=utf-8'
{noformat}
although JSON response is returned.
To reproduce, issue from the command line a simple 'read' operation
{noformat}
curl --digest -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation":"read-attribute", "name":"foo"}' -u <username>:<password>
..
Content-Type: text/plain; charset=utf-8
Content-Length: 119
Date: Sun, 23 Feb 2014 17:27:10 GMT
{
"outcome" : "failed",
"failure-description" : "JBAS014792: Unknown attribute foo",
"rolled-back" : true
}
{noformat}
The 'Content-Type' should have been set to *'application/json'* instead of *'text/plain'*
Note: On JBoss AS 7.1.1.Final, the correct type of *'application/json'* is returned for the same operation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1795 at 2/23/14 12:36 PM:
---------------------------------------------------------------------
Some problems with this test:
- the error message is a little wierd: messages 0-20 are 21 messages, not 20!
- the way that check works, we can't tell which channel has the incorrect number of messages. It would be better to check them separately like this:
{noformat}
check(NUM_MESSAGES,one);
check(NUM_MESAGES,two);
{noformat}
- related to the above comment, when an assertion is raised, it seems that we lose all test output and cant't see the output from the failed test. This is probably a problem with JUnitXMLReporter not closinjg a file correctly when the assertion is triggered. This probably affects all test cases in the same way.
was (Author: rachmato):
Some problems with this test:
- the error message is a little wierd: messages 0-20 are 21 messages, not 20!
- the way that check works, we can't tell which channel has the incorrect number of messages. It would be better to check them separately like this:
{noformat}
check(NUM_MESSAGES,one);
check(NUM_MESAGES,two);
{noformat}
- related to the above comment, when an assertion is raised, it seems that we lose all test output and cant't see the output from the failed test. This is probably a problem with JUnitXMLReporter.
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
> Key: JGRP-1795
> URL: https://issues.jboss.org/browse/JGRP-1795
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1795:
-------------------------------------------
The problem with the error message (which is only thrown if the assert is triggered) can be corrected this way:
{noformat}
private static void check(final int num_expected_msgs, Collection<Integer>... lists) {
for(Collection<Integer> list: lists) {
System.out.println("list: " + list);
}
for(Collection<Integer> list: lists) {
Collection<Integer> missing=new TreeSet<Integer>();
if(list.size() != num_expected_msgs) {
for(int i=1; i <= num_expected_msgs; i++) // this line changed
missing.add(i);
missing.removeAll(list);
assert list.size() == num_expected_msgs : "expected " + num_expected_msgs + " elements, but got " +
list.size() + " (list=" + list + "), missing=" + missing;
}
}
}
{noformat}
You are receiving integers [1,..,20] and creating the missing list from [0,..,19].
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
> Key: JGRP-1795
> URL: https://issues.jboss.org/browse/JGRP-1795
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1795 at 2/23/14 12:30 PM:
---------------------------------------------------------------------
Some problems with this test:
- the error message is a little wierd: messages 0-20 are 21 messages, not 20!
- the way that check works, we can't tell which channel has the incorrect number of messages. It would be better to check them separately like this:
{noformat}
check(NUM_MESSAGES,one);
check(NUM_MESAGES,two);
{noformat}
- related to the above comment, when an assertion is raised, it seems that we lose all test output and cant't see the output from the failed test. This is probably a problem with JUnitXMLReporter.
was (Author: rachmato):
Some problems with this test:
- the error message is a little wierd: messages 0-20 are 21 messages, not 20!
- the way that check works, we can't tell which channel has the incorrect number of messages. It would be better to check them separately like this:
{noformat}
check(NUM_MESSAGES,a);
check(NUM_MESAGES,b);
{noformat}
- related to the above comment, when an assertion is raised, it seems that we lose all test output and cant't see the output from the failed test. This is probably a problem with JUnitTestRunner.
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
> Key: JGRP-1795
> URL: https://issues.jboss.org/browse/JGRP-1795
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1795) OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1795?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1795:
-------------------------------------------
Some problems with this test:
- the error message is a little wierd: messages 0-20 are 21 messages, not 20!
- the way that check works, we can't tell which channel has the incorrect number of messages. It would be better to check them separately like this:
{noformat}
check(NUM_MESSAGES,a);
check(NUM_MESAGES,b);
{noformat}
- related to the above comment, when an assertion is raised, it seems that we lose all test output and cant't see the output from the failed test. This is probably a problem with JUnitTestRunner.
> OOBTest testRandomRegularAndOOBMulticasts fails to receive all messages
> -----------------------------------------------------------------------
>
> Key: JGRP-1795
> URL: https://issues.jboss.org/browse/JGRP-1795
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: RHEL(3/24), WIN (1/6), Solaris (6/24) where (x/y) means x failures over y test executions.
> Reporter: Richard Achmatowicz
> Assignee: Bela Ban
> Fix For: 3.2.13
>
>
> This test does the following with two channels a and b:
> - adds a DISCARD layer to a to disccard 50% of down messages
> - sends 20 messages to the group, randomly using a and b as senders, and randomly choosing OOB or non-OOB
> - wait 10 seconds for 20 messages to be received by each of a and b
> - print out the messages received
> - remove the DISCARD layer from a
> - wait 2.5 seconds for further messages to arrive
> - assert that 20 messages have arrived for each channel a and b
> The test fails on the assertion, with results such as:
> {noformat}
> expected 20 elements, but got 19 (list=[1, 4, 3, 8, 6, 7, 10, 13, 15, 20, 2, 5, 9, 12, 14, 16, 17, 18, 19]), missing=[0, 11]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months