[JBoss JIRA] (DROOLS-5078) Can't test against bigdecimal value in test scenario in business central
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5078?page=com.atlassian.jira.plug... ]
Yeser Amer edited comment on DROOLS-5078 at 6/3/20 9:24 AM:
------------------------------------------------------------
A new Error message is now shown, which should clarify how manage not supported FactTypes (eg. BigDecimal) using MVEL expressions.
was (Author: yamer):
A new Error message is now shown, which should clarify how manage not supported FactTypes (eg. BigDecimal) and to use MVEL expressions.
> Can't test against bigdecimal value in test scenario in business central
> ------------------------------------------------------------------------
>
> Key: DROOLS-5078
> URL: https://issues.redhat.com/browse/DROOLS-5078
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Werner Van Herrewegen
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: Applicant.java, Permille.scesim, image-2020-02-19-10-13-01-440.png
>
>
> I get the error : test failed with reason
> !image-2020-02-19-10-13-01-440.png|thumbnail!
> see screenshot
> 'class.java.math.bigdecimal is not supported'
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5078) Can't test against bigdecimal value in test scenario in business central
by Yeser Amer (Jira)
[ https://issues.redhat.com/browse/DROOLS-5078?page=com.atlassian.jira.plug... ]
Yeser Amer commented on DROOLS-5078:
------------------------------------
A new Error message is now shown, which should clarify how manage not supported FactTypes (eg. BigDecimal) and to use MVEL expressions.
> Can't test against bigdecimal value in test scenario in business central
> ------------------------------------------------------------------------
>
> Key: DROOLS-5078
> URL: https://issues.redhat.com/browse/DROOLS-5078
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing, Test Scenarios Editor
> Reporter: Werner Van Herrewegen
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
> Fix For: 7.39.0.Final
>
> Attachments: Applicant.java, Permille.scesim, image-2020-02-19-10-13-01-440.png
>
>
> I get the error : test failed with reason
> !image-2020-02-19-10-13-01-440.png|thumbnail!
> see screenshot
> 'class.java.math.bigdecimal is not supported'
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (DROOLS-5403) [Scesim Editor] Impossible to set collection element to null
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5403?page=com.atlassian.jira.plug... ]
Anna Dupliak reassigned DROOLS-5403:
------------------------------------
Component/s: Scenario Simulation and Testing
Tester: Anna Dupliak
Description:
If user tests collection of boolean/ enum /most of the complex type except String - that should contain a null value - it got a message:
"The expected value is '[{"value":"null"}]' but the actual one is 'null'."
If user follows the suggestion then he got unexpected error SEE: [^nullCollectionElement.webm]
Steps to Reproduce:
# Import [^MySpace_TestEnumTest2.zip]
# Go to testSurnameEnding
# Run test
Expected: test passed
Actual: test failing with
"The expected value is '[{"value":"null"}]' but the actual one is 'null'."
Attachment: MySpace_TestEnumTest2.zip
nullCollectionElement.webm
Affects Version/s: 7.39.0.Final
Assignee: Yeser Amer (was: Mario Fusco)
> [Scesim Editor] Impossible to set collection element to null
> ------------------------------------------------------------
>
> Key: DROOLS-5403
> URL: https://issues.redhat.com/browse/DROOLS-5403
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.39.0.Final
> Reporter: Anna Dupliak
> Assignee: Yeser Amer
> Priority: Major
> Attachments: MySpace_TestEnumTest2.zip, nullCollectionElement.webm
>
>
> If user tests collection of boolean/ enum /most of the complex type except String - that should contain a null value - it got a message:
> "The expected value is '[{"value":"null"}]' but the actual one is 'null'."
> If user follows the suggestion then he got unexpected error SEE: [^nullCollectionElement.webm]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1979) Elytron needs to deal with JEPS 244 in the org.wildfly.security.ssl package
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1979?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on ELY-1979:
---------------------------------------
This will get interesting.
Our build requires Java 11 as we have some multi module jars which allow us to use some later APIs to move away from some of the "workarounds" we needed when running against Java 8, as defined in jboss-parent we however still target Java 8:
{code:xml}
<maven.compiler.target>1.8</maven.compiler.target>
<maven.compiler.source>1.8</maven.compiler.source>
{code}
We then redefine the maven-compiler-plugin and set the release version to 8:
{code:xml}
<release>8</release>
{code}
This parameter is passed straight to javac, According to the documentation for the release parameter:
{quote}
Compiles against the public, supported and documented API for a specific VM version. Supported release targets are 6, 7, 8, 9, 10, and 11.
{quote}
https://docs.oracle.com/en/java/javase/11/tools/javac.html
It seems even the latest versions of Java 11 don't agree these new methods are part of the Java 8 API. If I remove the release setting the use of these new methods build cleanly but it does leave the project at risk of using API later than Java 8.
I can probably relax this check just for the affected component to get the changes through but we may now need an alternative API check to double check we don't accidentally introduce anything else new - so far this configuration has been quite reliable at providing the protection we need.
> Elytron needs to deal with JEPS 244 in the org.wildfly.security.ssl package
> ---------------------------------------------------------------------------
>
> Key: ELY-1979
> URL: https://issues.redhat.com/browse/ELY-1979
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.12.0.Final
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 1.12.1.CR1
>
>
> JEPS 244, available in JDK 9 or later and in JDK 8 since the 251 release[1] has added new methods to some of the javax.net.ssl classes that elytron wraps in org.wildfly.security.ssl. But the elytron classes do not handle those new methods. I believe the relevant change is at [2] and updates the SSLEngine, SSLParameters and SSLSocket classes (plus various non-javax classes.)
> If Elytron were to require 251 or later to build perhaps this could be a simple matter of adding new methods to the wrappers and calling the delegate, under the expectation that at runtime the wrapper methods would not be invoked in a JVM < 251. Or the wrappers could use reflection and throw a UOE if the methods are not available.
> [1] https://www.oracle.com/technetwork/java/javase/8u251-relnotes-5972664.htm...
> [2] https://hg.openjdk.java.net/jdk8u/jdk8u41/jdk/rev/b26b096d4c89
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month