[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 4/30/20 3:42 AM:
--------------------------------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly try to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
was (Author: tkobayashi):
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 4/30/20 3:42 AM:
--------------------------------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly tries to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
was (Author: tkobayashi):
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly try to find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5284:
-------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can teak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-5284 at 4/30/20 3:16 AM:
--------------------------------------------------------------------
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can tweak the selection logic as Double is preferred coercion for BigDecimal.
was (Author: tkobayashi):
First of all, the expression in the unit test is not good. Java cannot compile this because Math.round() can accept only double or float.
{code:java}
15 * Math.round( new BigDecimal("49.4") ) / 100
{code}
Then, MVEL kindly find a "BestCandidate" method for this.
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So MVEL picks up
{code:java}
public static int java.lang.Math.round(float)
{code}
or
{code:java}
public static long java.lang.Math.round(double)
{code}
(Assuming MVEL can coerce BigDecimal to float or double).
However, these 2 methods has no superiority in terms of scoring for "BestCandidate". Both get score "4".
https://github.com/mvel/mvel/blob/mvel2-2.4.7.Final/src/main/java/org/mve...
So the result depends on which method was picked first (The method lists are given by Class.getMethods()).
In case of OpenJDK, Math.round(double) is picked. -> Finally, the expression results in (Long / Long) which returns Double by MathProcessor.
In case of IBM JDK Math.round(float) is picked. -> Finally, the expression results in (Integer / Integer) which returns Integer by IntDiv.
I think I can teak the selection logic as Double is preferred coercion for BigDecimal.
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-5284:
-------------------------------------------
Also CoreConfidenceTests.testNumberCoercion in mvel repo fails.
{noformat}
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.118 sec <<< FAILURE! - in org.mvel2.tests.core.CoreConfidenceTests
testNumberCoercion(org.mvel2.tests.core.CoreConfidenceTests) Time elapsed: 0.087 sec <<< FAILURE!
junit.framework.AssertionFailedError: expected:<7.35> but was:<7>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:283)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:71)
at org.mvel2.tests.core.CoreConfidenceTests.testNumberCoercion(CoreConfidenceTests.java:4338)
Results :
Failed tests:
CoreConfidenceTests.testNumberCoercion:4338 expected:<7.35> but was:<7>
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
{noformat}
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5284?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi reassigned DROOLS-5284:
-----------------------------------------
Assignee: Toshiya Kobayashi (was: Mario Fusco)
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> ----------------------------------------------------------
>
> Key: DROOLS-5284
> URL: https://issues.redhat.com/browse/DROOLS-5284
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.36.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
> {noformat}
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
> [ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
> java.lang.AssertionError: expected:<7.350000> but was:<7>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
> ...
> [INFO]
> [INFO] Results:
> [INFO]
> [ERROR] Failures:
> [ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5284) MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5284:
-----------------------------------------
Summary: MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
Key: DROOLS-5284
URL: https://issues.redhat.com/browse/DROOLS-5284
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.36.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
MVELTest.testTypeCoercionLongDivByInt fails with IBM JDK 8
{noformat}
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.97 s <<< FAILURE! - in org.drools.compiler.integrationtests.MVELTest
[ERROR] testTypeCoercionLongDivByInt(org.drools.compiler.integrationtests.MVELTest) Time elapsed: 0.962 s <<< FAILURE!
java.lang.AssertionError: expected:<7.350000> but was:<7>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at org.drools.compiler.integrationtests.MVELTest.testTypeCoercionLongDivByInt(MVELTest.java:1150)
...
[INFO]
[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] MVELTest.testTypeCoercionLongDivByInt:1150 expected:<7.350000> but was:<7>
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFCORE-4952) Give a better error message for standard configuration tests
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFCORE-4952?page=com.atlassian.jira.plug... ]
James Perkins updated WFCORE-4952:
----------------------------------
Priority: Minor (was: Major)
> Give a better error message for standard configuration tests
> ------------------------------------------------------------
>
> Key: WFCORE-4952
> URL: https://issues.redhat.com/browse/WFCORE-4952
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Test Suite
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> The {{StandardConfigsXMLValidationUnitTestCase}} tests validate the default configuration files. These are written into a file as a single line. This makes it a little more difficult to determine where the error is.
> A simple fix for this is to just write a new line after each line. This will give a better error message as to which line the issue is one.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFCORE-4952) Give a better error message for standard configuration tests
by James Perkins (Jira)
James Perkins created WFCORE-4952:
-------------------------------------
Summary: Give a better error message for standard configuration tests
Key: WFCORE-4952
URL: https://issues.redhat.com/browse/WFCORE-4952
Project: WildFly Core
Issue Type: Enhancement
Components: Test Suite
Reporter: James Perkins
Assignee: James Perkins
The {{StandardConfigsXMLValidationUnitTestCase}} tests validate the default configuration files. These are written into a file as a single line. This makes it a little more difficult to determine where the error is.
A simple fix for this is to just write a new line after each line. This will give a better error message as to which line the issue is one.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months