[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-10630:
-------------------------------------------
[~bkabelka] Im following instructions from README.md . Ive tinkered a bit( mostly with file location/url and +{noformat}@POST {noformat} in POJOs(+add-user.sh). I could get past initial error(405 on POST) but thats it. Could you please check against latest WFLY master(possibly update reproducer) and attach steps + all conf files?
> HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10630
> URL: https://issues.jboss.org/browse/WFLY-10630
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Environment: Windows 10, Java 1.8.0_131
> Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
> Reporter: Bernhard Kabelka
> Assignee: Bartosz Baranowski
>
> For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
> I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
> In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
> In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
> * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
> * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2814:
----------------------------------
Tester: Tibor Zimányi
> MVEL uses random parameter type methods for BigDecimal.valueOf(100)
> -------------------------------------------------------------------
>
> Key: DROOLS-2814
> URL: https://issues.jboss.org/browse/DROOLS-2814
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.9.0.Final
> Environment: - MVEL2 2.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
> Attachments: BigDecimalMvelTest.zip
>
>
> When MVEL evaluates
> {noformat}
> java.math.BigDecimal.valueOf(100)
> {noformat}
> , MVEL determines a method from valueOf(double val) or valueOf(long val).
> The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
> ParseTools.getMethodScore() gives the same score for double and long.
> https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
> So a selected method will depend on the order of result of "cls.getMethods()".
> Reproducer:
> $ unzip BigDecimalMvelTest.zip
> $ cd BigDecimalMvelTest
> $ mvn compile
> $ ./loop.sh
> It runs the MVEL test 100 times:
> {noformat}
> $ ./loop.sh
> result = 100.0
> result = 100.0
> result = 100.0
> result = 100
> result = 100.0
> result = 100.0
> ...
> {noformat}
> In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
> Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2815) [DMN Designer] Make Expression Type dependent on Diagram Node
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2815?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2815:
--------------------------------
Description:
The expression editor options should be dependent on the diagram node type.
h2. Decision Node
Should allow all expression types except of *Function*
h2. BKM Node
Should allow only *Function* expression type.
h3. Further improvement
BKM node has automatically function expression inside - separate jira, or won't be implemented?
h2. Acceptance tests
- Not possible to set *function expression type* for Decision node
- Possible to set just *function expression type* for BKM node
-- Created automatically if we decide to implement here
- Dialog shown if opened file from external tool that doesn't follow this restriction
was:
The expression editor options should be dependent on the diagram node type.
h3. Decision Node
Should allow all expression types except of *Function*
h3. BKM Node
Should allow only *Function* expression type.
h4. Further improvement
BKM node has automatically function expression inside - separate jira, or won't be implemented?
h3. Acceptance tests
- Not possible to set *function expression type* for Decision node
- Possible to set just *function expression type* for BKM node
-- Created automatically if we decide to implement here
- Dialog shown if opened file from external tool that doesn't follow this restriction
> [DMN Designer] Make Expression Type dependent on Diagram Node
> -------------------------------------------------------------
>
> Key: DROOLS-2815
> URL: https://issues.jboss.org/browse/DROOLS-2815
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.9.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: drools-tools
>
> The expression editor options should be dependent on the diagram node type.
> h2. Decision Node
> Should allow all expression types except of *Function*
> h2. BKM Node
> Should allow only *Function* expression type.
> h3. Further improvement
> BKM node has automatically function expression inside - separate jira, or won't be implemented?
> h2. Acceptance tests
> - Not possible to set *function expression type* for Decision node
> - Possible to set just *function expression type* for BKM node
> -- Created automatically if we decide to implement here
> - Dialog shown if opened file from external tool that doesn't follow this restriction
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2815) [DMN Designer] Make Expression Type dependent on Diagram Node
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-2815:
-----------------------------------
Summary: [DMN Designer] Make Expression Type dependent on Diagram Node
Key: DROOLS-2815
URL: https://issues.jboss.org/browse/DROOLS-2815
Project: Drools
Issue Type: Feature Request
Components: DMN Editor
Affects Versions: 7.9.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
The expression editor options should be dependent on the diagram node type.
h3. Decision Node
Should allow all expression types except of *Function*
h3. BKM Node
Should allow only *Function* expression type.
h4. Further improvement
BKM node has automatically function expression inside - separate jira, or won't be implemented?
h3. Acceptance tests
- Not possible to set *function expression type* for Decision node
- Possible to set just *function expression type* for BKM node
-- Created automatically if we decide to implement here
- Dialog shown if opened file from external tool that doesn't follow this restriction
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-2814:
--------------------------------------
Description:
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
was:
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (e.g. considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
> MVEL uses random parameter type methods for BigDecimal.valueOf(100)
> -------------------------------------------------------------------
>
> Key: DROOLS-2814
> URL: https://issues.jboss.org/browse/DROOLS-2814
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.9.0.Final
> Environment: - MVEL2 2.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
> Attachments: BigDecimalMvelTest.zip
>
>
> When MVEL evaluates
> {noformat}
> java.math.BigDecimal.valueOf(100)
> {noformat}
> , MVEL determines a method from valueOf(double val) or valueOf(long val).
> The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
> ParseTools.getMethodScore() gives the same score for double and long.
> https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
> So a selected method will depend on the order of result of "cls.getMethods()".
> Reproducer:
> $ unzip BigDecimalMvelTest.zip
> $ cd BigDecimalMvelTest
> $ mvn compile
> $ ./loop.sh
> It runs the MVEL test 100 times:
> {noformat}
> $ ./loop.sh
> result = 100.0
> result = 100.0
> result = 100.0
> result = 100
> result = 100.0
> result = 100.0
> ...
> {noformat}
> In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
> Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-2814:
--------------------------------------
Description:
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (e.g. considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
was:
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int.
> MVEL uses random parameter type methods for BigDecimal.valueOf(100)
> -------------------------------------------------------------------
>
> Key: DROOLS-2814
> URL: https://issues.jboss.org/browse/DROOLS-2814
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.9.0.Final
> Environment: - MVEL2 2.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
> Attachments: BigDecimalMvelTest.zip
>
>
> When MVEL evaluates
> {noformat}
> java.math.BigDecimal.valueOf(100)
> {noformat}
> , MVEL determines a method from valueOf(double val) or valueOf(long val).
> The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
> ParseTools.getMethodScore() gives the same score for double and long.
> https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
> So a selected method will depend on the order of result of "cls.getMethods()".
> Reproducer:
> $ unzip BigDecimalMvelTest.zip
> $ cd BigDecimalMvelTest
> $ mvn compile
> $ ./loop.sh
> It runs the MVEL test 100 times:
> {noformat}
> $ ./loop.sh
> result = 100.0
> result = 100.0
> result = 100.0
> result = 100
> result = 100.0
> result = 100.0
> ...
> {noformat}
> In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
> Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int. (e.g. considering "direct supertype" https://docs.oracle.com/javase/specs/jls/se8/html/jls-4.html#jls-4.10)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (WFLY-10630) HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10630?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski edited comment on WFLY-10630 at 8/1/18 1:30 AM:
-------------------------------------------------------------------
[~bkabelka] Yeah, this wont cut it:
{quote}
HTTP ERROR 405
{quote}
{quote}
10:09:28,362 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002010: Failed to execute: javax.ws.rs.NotAllowedException: RESTEASY003650: No resource method found for POST, return 405 with Allow header
at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:455)
at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:141)
{quote}
Ive set up domain like:
{noformat}
<subsystem xmlns="urn:jboss:domain:security:2.0">
<security-domains>
....
<security-domain name="sessionlistener">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file://${jboss.server.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="file://${jboss.server.config.dir}/application-roles.properties"/>
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
{noformat}
was (Author: baranowb):
[~bkabelka] Yeah, this wont cut it:
{quote}
HTTP ERROR 405
{quote}
{quote}
10:09:28,362 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1) RESTEASY002010: Failed to execute: javax.ws.rs.NotAllowedException: RESTEASY003650: No resource method found for POST, return 405 with Allow header
at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:455)
at org.jboss.resteasy.core.registry.SegmentNode.match(SegmentNode.java:141)
{quote}
Ive set up domain like:
{quote}
<subsystem xmlns="urn:jboss:domain:security:2.0">
<security-domains>
....
<security-domain name="sessionlistener">
<authentication>
<login-module code="UsersRoles" flag="required">
<module-option name="usersProperties" value="file://${jboss.server.config.dir}/application-users.properties"/>
<module-option name="rolesProperties" value="file://${jboss.server.config.dir}/application-roles.properties"/>
</login-module>
</authentication>
</security-domain>
</security-domains>
</subsystem>
{quote}
> HttpSessionListener.sessionDestroyed() not called if session invalidated in another WAR
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10630
> URL: https://issues.jboss.org/browse/WFLY-10630
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final, 13.0.0.Final
> Environment: Windows 10, Java 1.8.0_131
> Reproducible with both WildFly-10.0.0.Final and Wildfly-13.0.0.Final
> Reporter: Bernhard Kabelka
> Assignee: Bartosz Baranowski
>
> For sessions shared across different WARs in a single EAR, the notification of HttpSessionListener works differently in WildFly 10.0.0.Final (and Wildfly 13.0.0.Final) than it it used to work in WildFly 8.2.0.Final:
> I have an EAR containing two WARs with enabled session sharing across the WARs. Basically, one WAR contains the web UI, and the other WAR contains the REST interfaces for AJAX calls made by the UI. The user authenticates against the UI-WAR. On logout, a REST method in the AJAX-WAR is triggered which calls HttpSession.invalidate() on the user session.
> In WildFly 8.2.0.Final, a HttpSessionListener in the UI-WAR gets notified immediately about session creation and destruction.
> In WildFly 13.0.0.Final, however, a HttpSessionListener in either WAR only gets one of the two notifications:
> * In the UI-WAR, I get a notification about the created session immediately when the login form is loaded. However, I do not receive any notification about the session destruction (unless it times out).
> * In the AJAX-WAR, I do not get any notification about the session creation at all, but I immediately receive a notification about the session destruction.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi commented on DROOLS-2814:
-------------------------------------------
I can understand that the right usage is to use Double or Long explicitly ("100d" or "100L"). But random results don't seem to be good.
> MVEL uses random parameter type methods for BigDecimal.valueOf(100)
> -------------------------------------------------------------------
>
> Key: DROOLS-2814
> URL: https://issues.jboss.org/browse/DROOLS-2814
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.9.0.Final
> Environment: - MVEL2 2.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
> Attachments: BigDecimalMvelTest.zip
>
>
> When MVEL evaluates
> {noformat}
> java.math.BigDecimal.valueOf(100)
> {noformat}
> , MVEL determines a method from valueOf(double val) or valueOf(long val).
> The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
> ParseTools.getMethodScore() gives the same score for double and long.
> https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
> So a selected method will depend on the order of result of "cls.getMethods()".
> Reproducer:
> $ unzip BigDecimalMvelTest.zip
> $ cd BigDecimalMvelTest
> $ mvn compile
> $ ./loop.sh
> It runs the MVEL test 100 times:
> {noformat}
> $ ./loop.sh
> result = 100.0
> result = 100.0
> result = 100.0
> result = 100
> result = 100.0
> result = 100.0
> ...
> {noformat}
> In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
> Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)
by Toshiya Kobayashi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2814?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-2814:
--------------------------------------
Attachment: BigDecimalMvelTest.zip
> MVEL uses random parameter type methods for BigDecimal.valueOf(100)
> -------------------------------------------------------------------
>
> Key: DROOLS-2814
> URL: https://issues.jboss.org/browse/DROOLS-2814
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.9.0.Final
> Environment: - MVEL2 2.4.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Mario Fusco
> Labels: support
> Attachments: BigDecimalMvelTest.zip
>
>
> When MVEL evaluates
> {noformat}
> java.math.BigDecimal.valueOf(100)
> {noformat}
> , MVEL determines a method from valueOf(double val) or valueOf(long val).
> The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
> ParseTools.getMethodScore() gives the same score for double and long.
> https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
> So a selected method will depend on the order of result of "cls.getMethods()".
> Reproducer:
> $ unzip BigDecimalMvelTest.zip
> $ cd BigDecimalMvelTest
> $ mvn compile
> $ ./loop.sh
> It runs the MVEL test 100 times:
> {noformat}
> $ ./loop.sh
> result = 100.0
> result = 100.0
> result = 100.0
> result = 100
> result = 100.0
> result = 100.0
> ...
> {noformat}
> In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
> Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months
[JBoss JIRA] (DROOLS-2814) MVEL uses random parameter type methods for BigDecimal.valueOf(100)
by Toshiya Kobayashi (JIRA)
Toshiya Kobayashi created DROOLS-2814:
-----------------------------------------
Summary: MVEL uses random parameter type methods for BigDecimal.valueOf(100)
Key: DROOLS-2814
URL: https://issues.jboss.org/browse/DROOLS-2814
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.9.0.Final
Environment: - MVEL2 2.4.0.Final
Reporter: Toshiya Kobayashi
Assignee: Mario Fusco
When MVEL evaluates
{noformat}
java.math.BigDecimal.valueOf(100)
{noformat}
, MVEL determines a method from valueOf(double val) or valueOf(long val).
The result is not consistent. Sometimes uses valueOf(double val), Sometimes uses valueOf(long val).
ParseTools.getMethodScore() gives the same score for double and long.
https://github.com/mvel/mvel/blob/master/src/main/java/org/mvel2/util/Par...
So a selected method will depend on the order of result of "cls.getMethods()".
Reproducer:
$ unzip BigDecimalMvelTest.zip
$ cd BigDecimalMvelTest
$ mvn compile
$ ./loop.sh
It runs the MVEL test 100 times:
{noformat}
$ ./loop.sh
result = 100.0
result = 100.0
result = 100.0
result = 100
result = 100.0
result = 100.0
...
{noformat}
In my environment, "100.0" is the majority but randomly see "100" as well. (I couldn't reproduce with single run with java for loop)
Expectation is constantly "100" (using valueOf(long val)) because in case of usual Java "java.math.BigDecimal.valueOf(100)", Java compiler chooses valueOf(long val) if the parameter is int.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 4 months