[JBoss JIRA] (WFLY-13414) Upgrade WildFly Core 11.1.1.Final
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFLY-13414?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFLY-13414:
-------------------------------
Description:
Artifacts for WildFly Core 11.1.0.Final were corrupted during the build.
We will upgrade to WildFly Core 11.1.1.Final (that contains no changes compared to 11.1.0.Final)
> Upgrade WildFly Core 11.1.1.Final
> ---------------------------------
>
> Key: WFLY-13414
> URL: https://issues.redhat.com/browse/WFLY-13414
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Management
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Blocker
> Fix For: 19.1.0.Final
>
>
> Artifacts for WildFly Core 11.1.0.Final were corrupted during the build.
> We will upgrade to WildFly Core 11.1.1.Final (that contains no changes compared to 11.1.0.Final)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4950) Regression: Legacy Ldap Realm securing EJB with JDK8 not working
by Ricardo Martin Camarero (Jira)
[ https://issues.redhat.com/browse/WFCORE-4950?page=com.atlassian.jira.plug... ]
Ricardo Martin Camarero commented on WFCORE-4950:
-------------------------------------------------
Checking the changes in the {{module.xml}} file for that module:
1. The {{sun.jdk}} was removed in [WFCORE-3705|https://github.com/wildfly/wildfly-core/commit/b48ea664f81299...] when new jdk modules were integrated.
2. But later {{java.naming}} was added in a workaround for [WFLY-10394|https://github.com/wildfly/wildfly-core/commit/8d52d23e3158723...] and it includes the class {{com.sun.jndi.ldap.LdapCtxFactory}}.
3. But {{java.naming}} was removed later in [WFCORE-4531|https://github.com/wildfly/wildfly-core/commit/08bbe43df448b4...].
4. But between 2 and 3 the module {{jdk.security.auth}} was added in [WFCORE-3889|https://github.com/wildfly/wildfly-core/commit/81b9a7c64b9a27...], which in jdk requires transitive the {{java.naming}} ([see this|https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/jdk.secu...]). That makes it work in jdk-11 (removing that module I see the same exception using jdk-11).
So I'm going to add back the {{java.naming}} module, I think that it is included in jdk-11 because of the transitive tag but not in jdk-8 (jboss-modules seems to not add that transitive inclusion). I'll send the PR and we can argue about it later.
> Regression: Legacy Ldap Realm securing EJB with JDK8 not working
> ----------------------------------------------------------------
>
> Key: WFCORE-4950
> URL: https://issues.redhat.com/browse/WFCORE-4950
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ricardo Martin Camarero
> Assignee: Ricardo Martin Camarero
> Priority: Critical
>
> WFCORE issue related to JBEAP-19195. The root exception is the following:
> {noformat}
> javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]]
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.InitialContext.<init>(InitialContext.java:216)
> at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:272)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:184)
> at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:180)
> at org.jboss.as.domain.management.security.LdapConnectionHandler.getConnection(LdapConnectionHandler.java:78)
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125)
> at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66)
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:232)
> at org.jboss.as.domain.management.security.UserLdapCallbackHandler$SecurityRealmImpl.getRealmIdentity(UserLdapCallbackHandler.java:339)
> at org.jboss.as.domain.management.security.SecurityRealmService$SharedStateSecurityRealm.getRealmIdentity(SecurityRealmService.java:776)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.assignName(ServerAuthenticationContext.java:1197)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$UnassignedState.setPrincipal(ServerAuthenticationContext.java:1726)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationPrincipal(ServerAuthenticationContext.java:410)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:384)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:368)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:912)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:853)
> at org.wildfly.security.auth.callback.SocketAddressQueryCallbackHandler.handle(SocketAddressQueryCallbackHandler.java:57)
> at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:105)
> at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:118)
> at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58)
> at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:110)
> at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245)
> at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217)
> at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:484)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115)
> ... 40 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[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:45 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 have 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 from a method list (The method list is 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 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.
> 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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years
[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)
6 years