[JBoss JIRA] (DROOLS-4288) Infinite recursion in drools after version change from v7.20 to v7.21
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4288?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-4288:
-------------------------------------
[~dacr] Sorry but I don't see any new attachment. Please attach your reproducer to DROOLS-4909
> Infinite recursion in drools after version change from v7.20 to v7.21
> ---------------------------------------------------------------------
>
> Key: DROOLS-4288
> URL: https://issues.redhat.com/browse/DROOLS-4288
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final
> Environment: Both Mac and Windows
> Reporter: Geogie Tom
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.25.0.Final
>
> Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png
>
>
> When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively.
> *Code in github:*
> [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20]
> [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21]
> [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *More details*
> When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part:
> {code:java}
> rule "rule 1.1"
> when
> $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable")
> then
> System.out.println("Rule 1.1 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it doesn't loop recursively.
> But when I call another rule which call a static function from another class:
> {code:java}
> rule "rule 1.2"
> when
> $sampleDomain: SampleDomain(CoreUtils.anotherFunction())
> then
> System.out.println("Rule 1.2 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it loops recursively.
> The class with static function is
> {code:java}
> import com.drool_issue.domain.SampleDomain;
> public class CoreUtils {
>
> public static boolean anotherFunction() {
> System.out.println("anotherFunction() inside CoreUtils");
> return true;
> }
>
> public static boolean anotherFunction(SampleDomain sampleDomain) {
> System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils");
> return true;
> }
> }
> {code}
> My domain file is:
> {code:java}
> public class SampleDomain {
> private int instanceVariable1;
> private String instanceVariable2;
> private int instanceVariable3;
>
>
> public int getInstanceVariable1() {
> return instanceVariable1;
> }
> public void setInstanceVariable1(int instanceVariable1) {
> this.instanceVariable1 = instanceVariable1;
> }
> public String getInstanceVariable2() {
> return instanceVariable2;
> }
> public void setInstanceVariable2(String instanceVariable2) {
> this.instanceVariable2 = instanceVariable2;
> }
> public int getInstanceVariable3() {
> return instanceVariable3;
> }
> public void setInstanceVariable3(int instanceVariable3) {
> this.instanceVariable3 = instanceVariable3;
> }
>
>
> }
> {code}
> This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be?
> When I further looked into the problem I saw this too.
> When we add two functions into the `SampleDomain` class ie
> {code:java}
> public boolean anotherFunction() {
> return true;
> }
>
> public boolean anotherFunction(SampleDomain sampleDomain) {
> return true;
> }
> {code}
> and use this in the rule like:
> {code:java}
> rule "rule 1.4"
> when
> $sampleDomain: SampleDomain(anotherFunction())
> then
> System.out.println("Rule 1.4 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> and
> {code:java}
> rule "rule 1.5"
> when
> $sampleDomain: SampleDomain(anotherFunction($sampleDomain))
> then
> System.out.println("Rule 1.5 fired");
> modify($sampleDomain){
> setInstanceVariable3(4)
> }
> end
> {code}
> these also loops recursively.
> *Code in github:*
> [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule.
> *Code portions to be noted here are:*
> [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *Code in github:*
> [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4288) Infinite recursion in drools after version change from v7.20 to v7.21
by Crosson David (Jira)
[ https://issues.redhat.com/browse/DROOLS-4288?page=com.atlassian.jira.plug... ]
Crosson David commented on DROOLS-4288:
---------------------------------------
OK by adding enough complexity I was able to reproduce the issue see attached KB :)
> Infinite recursion in drools after version change from v7.20 to v7.21
> ---------------------------------------------------------------------
>
> Key: DROOLS-4288
> URL: https://issues.redhat.com/browse/DROOLS-4288
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final
> Environment: Both Mac and Windows
> Reporter: Geogie Tom
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.25.0.Final
>
> Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png
>
>
> When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively.
> *Code in github:*
> [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20]
> [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21]
> [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *More details*
> When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part:
> {code:java}
> rule "rule 1.1"
> when
> $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable")
> then
> System.out.println("Rule 1.1 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it doesn't loop recursively.
> But when I call another rule which call a static function from another class:
> {code:java}
> rule "rule 1.2"
> when
> $sampleDomain: SampleDomain(CoreUtils.anotherFunction())
> then
> System.out.println("Rule 1.2 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it loops recursively.
> The class with static function is
> {code:java}
> import com.drool_issue.domain.SampleDomain;
> public class CoreUtils {
>
> public static boolean anotherFunction() {
> System.out.println("anotherFunction() inside CoreUtils");
> return true;
> }
>
> public static boolean anotherFunction(SampleDomain sampleDomain) {
> System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils");
> return true;
> }
> }
> {code}
> My domain file is:
> {code:java}
> public class SampleDomain {
> private int instanceVariable1;
> private String instanceVariable2;
> private int instanceVariable3;
>
>
> public int getInstanceVariable1() {
> return instanceVariable1;
> }
> public void setInstanceVariable1(int instanceVariable1) {
> this.instanceVariable1 = instanceVariable1;
> }
> public String getInstanceVariable2() {
> return instanceVariable2;
> }
> public void setInstanceVariable2(String instanceVariable2) {
> this.instanceVariable2 = instanceVariable2;
> }
> public int getInstanceVariable3() {
> return instanceVariable3;
> }
> public void setInstanceVariable3(int instanceVariable3) {
> this.instanceVariable3 = instanceVariable3;
> }
>
>
> }
> {code}
> This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be?
> When I further looked into the problem I saw this too.
> When we add two functions into the `SampleDomain` class ie
> {code:java}
> public boolean anotherFunction() {
> return true;
> }
>
> public boolean anotherFunction(SampleDomain sampleDomain) {
> return true;
> }
> {code}
> and use this in the rule like:
> {code:java}
> rule "rule 1.4"
> when
> $sampleDomain: SampleDomain(anotherFunction())
> then
> System.out.println("Rule 1.4 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> and
> {code:java}
> rule "rule 1.5"
> when
> $sampleDomain: SampleDomain(anotherFunction($sampleDomain))
> then
> System.out.println("Rule 1.5 fired");
> modify($sampleDomain){
> setInstanceVariable3(4)
> }
> end
> {code}
> these also loops recursively.
> *Code in github:*
> [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule.
> *Code portions to be noted here are:*
> [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *Code in github:*
> [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-291) Log messages from io.smallrye.openapi don't have message ID
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-291?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti commented on WFWIP-291:
----------------------------------------
Hi [~pferraro], I do not agree on the argument that log message IDs are intended only for what relates to internationalization.
Those can in fact be used to perform automated log observation, statistics and so on.
These activities are then even more important in a cloud native/orchestrated environment, where systems and components do interoperation, and we know MicroProfile specs are definitely relating to this kind of environment.
So I am asking for you to keep this issue open as the topic is common to all MP specs we're integrating and there are similar issues that haven't been closed, see for instance https://issues.redhat.com/browse/WFWIP-280. My propposal is to re open it and wait until some common approach to the topic is decided.
[~rsvoboda] WDYT?
[~dlofthouse], thanks for your information.
Once again, I don't really think this is _just_ about internationalization.
That said, although I can I agree on your first argument:
{quote}
Additionally there is also a general issue in that we can not impose our own logging formats on third party projects pulled into WildFly.
If a third party project throws an Exception we can catch we may have an opportunity to catch and log with an ID or rethrow with an ID but we don't have options to intercept messages directly logged.
{quote}
... it's definitely good to know that SmallRye is being receptive to our feedback, as it could become important once Wildfly end users will notice that - for instance - they cannot search the Internet or the community/product docs for a message ID but for a variable text message.
Finally, I'd like to point out that in current MP OpenAPI SmallRye implementation, even WARNs and INFOs are not given a message ID:
{quote}
$ find . -name '*.*' -type f -print0 | xargs -0 grep --color -n -e 'LOG.warn'
./implementation/src/main/java/io/smallrye/openapi/runtime/scanner/ParameterProcessor.java:551: LOG.warnf("Matrix parameter references missing path segment: %s", segmentName);
{quote}
> Log messages from io.smallrye.openapi don't have message ID
> -----------------------------------------------------------
>
> Key: WFWIP-291
> URL: https://issues.redhat.com/browse/WFWIP-291
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP OpenAPI
> Reporter: Fabio Burzigotti
> Assignee: Paul Ferraro
> Priority: Major
>
> Messages logged by io.smallrye.openapi don't have assigned ID:
> {code}
> 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.util.SchemaFactory] (MSC service thread 1-4) Processing a single @Schema annotation.
> 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner] (MSC service thread 1-4) Processing a single @Response annotation.
> 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.scanner.OpenApiAnnotationScanner] (MSC service thread 1-4) Processing jax-rs method: {0}
> 2020-01-05 16:58:49,225 DEBUG [io.smallrye.openapi.runtime.scanner.OpenApiDataObjectScanner] (MSC service thread 1-4) Starting processing with root: java.lang.String
> {code}
> A search in SmallRye implementation seems to show that IDs are not used even when level is WARN:
> {code}
> $ find . -name '*.*' -type f -print0 | xargs -0 grep --color -n -e 'LOG.warn'
> ./implementation/src/main/java/io/smallrye/openapi/runtime/scanner/ParameterProcessor.java:551: LOG.warnf("Matrix parameter references missing path segment: %s", segmentName);
> ./implementation/src/main/java/io/smallrye/openapi/runtime/scanner/ParameterProcessor.java:1147: LOG.warnf("Value '%s' is not a valid %s default", stringValue, primitive.name().toLowerCase());
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4288) Infinite recursion in drools after version change from v7.20 to v7.21
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-4288?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-4288:
-------------------------------------
Just a wild guess, is it possible that you have 2 rules calling each other instead? As soon as you have a reproducer please attach it to DROOLS-4909 and leave this ticket closed. Thanks again.
> Infinite recursion in drools after version change from v7.20 to v7.21
> ---------------------------------------------------------------------
>
> Key: DROOLS-4288
> URL: https://issues.redhat.com/browse/DROOLS-4288
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final
> Environment: Both Mac and Windows
> Reporter: Geogie Tom
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.25.0.Final
>
> Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png
>
>
> When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively.
> *Code in github:*
> [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20]
> [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21]
> [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *More details*
> When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part:
> {code:java}
> rule "rule 1.1"
> when
> $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable")
> then
> System.out.println("Rule 1.1 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it doesn't loop recursively.
> But when I call another rule which call a static function from another class:
> {code:java}
> rule "rule 1.2"
> when
> $sampleDomain: SampleDomain(CoreUtils.anotherFunction())
> then
> System.out.println("Rule 1.2 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it loops recursively.
> The class with static function is
> {code:java}
> import com.drool_issue.domain.SampleDomain;
> public class CoreUtils {
>
> public static boolean anotherFunction() {
> System.out.println("anotherFunction() inside CoreUtils");
> return true;
> }
>
> public static boolean anotherFunction(SampleDomain sampleDomain) {
> System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils");
> return true;
> }
> }
> {code}
> My domain file is:
> {code:java}
> public class SampleDomain {
> private int instanceVariable1;
> private String instanceVariable2;
> private int instanceVariable3;
>
>
> public int getInstanceVariable1() {
> return instanceVariable1;
> }
> public void setInstanceVariable1(int instanceVariable1) {
> this.instanceVariable1 = instanceVariable1;
> }
> public String getInstanceVariable2() {
> return instanceVariable2;
> }
> public void setInstanceVariable2(String instanceVariable2) {
> this.instanceVariable2 = instanceVariable2;
> }
> public int getInstanceVariable3() {
> return instanceVariable3;
> }
> public void setInstanceVariable3(int instanceVariable3) {
> this.instanceVariable3 = instanceVariable3;
> }
>
>
> }
> {code}
> This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be?
> When I further looked into the problem I saw this too.
> When we add two functions into the `SampleDomain` class ie
> {code:java}
> public boolean anotherFunction() {
> return true;
> }
>
> public boolean anotherFunction(SampleDomain sampleDomain) {
> return true;
> }
> {code}
> and use this in the rule like:
> {code:java}
> rule "rule 1.4"
> when
> $sampleDomain: SampleDomain(anotherFunction())
> then
> System.out.println("Rule 1.4 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> and
> {code:java}
> rule "rule 1.5"
> when
> $sampleDomain: SampleDomain(anotherFunction($sampleDomain))
> then
> System.out.println("Rule 1.5 fired");
> modify($sampleDomain){
> setInstanceVariable3(4)
> }
> end
> {code}
> these also loops recursively.
> *Code in github:*
> [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule.
> *Code portions to be noted here are:*
> [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *Code in github:*
> [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header
by Fabio Burzigotti (Jira)
[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ]
Fabio Burzigotti commented on WFWIP-290:
----------------------------------------
Hi [~pferraro], I see that the original issue has been fixed on feature branch (commit **803a542bba53b30bacf4c0003d46838191c6afd3**) and HTTP 406 is now returned for all unacceptable types, although I can see that - when sending "Accept: application/*", then HTTP 200 is returned with "application/yaml" Content-Type.
Is this behavior wanted?
> Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-290
> URL: https://issues.redhat.com/browse/WFWIP-290
> Project: WildFly WIP
> Issue Type: Bug
> Components: MP OpenAPI
> Reporter: Fabio Burzigotti
> Assignee: Paul Ferraro
> Priority: Major
>
> When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned.
> This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4288) Infinite recursion in drools after version change from v7.20 to v7.21
by Crosson David (Jira)
[ https://issues.redhat.com/browse/DROOLS-4288?page=com.atlassian.jira.plug... ]
Crosson David commented on DROOLS-4288:
---------------------------------------
Yes I'm still trying to reproduce the issue, I've already spent almost 1.5 day on it, trying to understand why it loops although it shouldn't as there is no constraint on the "value" property... I really don't understand what's going on in particular because the several sharable examples I've built until now are still not affected by the issue :(. As soon as I've been able to build a reproductible example I'll share it to you, this is very strange.
> Infinite recursion in drools after version change from v7.20 to v7.21
> ---------------------------------------------------------------------
>
> Key: DROOLS-4288
> URL: https://issues.redhat.com/browse/DROOLS-4288
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final
> Environment: Both Mac and Windows
> Reporter: Geogie Tom
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.25.0.Final
>
> Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png
>
>
> When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively.
> *Code in github:*
> [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20]
> [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21]
> [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *More details*
> When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part:
> {code:java}
> rule "rule 1.1"
> when
> $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable")
> then
> System.out.println("Rule 1.1 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it doesn't loop recursively.
> But when I call another rule which call a static function from another class:
> {code:java}
> rule "rule 1.2"
> when
> $sampleDomain: SampleDomain(CoreUtils.anotherFunction())
> then
> System.out.println("Rule 1.2 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> it loops recursively.
> The class with static function is
> {code:java}
> import com.drool_issue.domain.SampleDomain;
> public class CoreUtils {
>
> public static boolean anotherFunction() {
> System.out.println("anotherFunction() inside CoreUtils");
> return true;
> }
>
> public static boolean anotherFunction(SampleDomain sampleDomain) {
> System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils");
> return true;
> }
> }
> {code}
> My domain file is:
> {code:java}
> public class SampleDomain {
> private int instanceVariable1;
> private String instanceVariable2;
> private int instanceVariable3;
>
>
> public int getInstanceVariable1() {
> return instanceVariable1;
> }
> public void setInstanceVariable1(int instanceVariable1) {
> this.instanceVariable1 = instanceVariable1;
> }
> public String getInstanceVariable2() {
> return instanceVariable2;
> }
> public void setInstanceVariable2(String instanceVariable2) {
> this.instanceVariable2 = instanceVariable2;
> }
> public int getInstanceVariable3() {
> return instanceVariable3;
> }
> public void setInstanceVariable3(int instanceVariable3) {
> this.instanceVariable3 = instanceVariable3;
> }
>
>
> }
> {code}
> This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be?
> When I further looked into the problem I saw this too.
> When we add two functions into the `SampleDomain` class ie
> {code:java}
> public boolean anotherFunction() {
> return true;
> }
>
> public boolean anotherFunction(SampleDomain sampleDomain) {
> return true;
> }
> {code}
> and use this in the rule like:
> {code:java}
> rule "rule 1.4"
> when
> $sampleDomain: SampleDomain(anotherFunction())
> then
> System.out.println("Rule 1.4 fired");
> modify($sampleDomain){
> setInstanceVariable1(3)
> }
> end
> {code}
> and
> {code:java}
> rule "rule 1.5"
> when
> $sampleDomain: SampleDomain(anotherFunction($sampleDomain))
> then
> System.out.println("Rule 1.5 fired");
> modify($sampleDomain){
> setInstanceVariable3(4)
> }
> end
> {code}
> these also loops recursively.
> *Code in github:*
> [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule.
> *Code portions to be noted here are:*
> [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...]
> [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *Code in github:*
> [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...]
> [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...]
> *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`*
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-3879) Create Kogito version of Test Scenarios designer
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-3879?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-3879:
-------------------------------------
Description:
Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor.
>From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`.
Access to it has been "hided" behind a wrapper interface with three actual implementations:
* `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment
* `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment
* `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode).
As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place.
Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach.
Kogito-testing module is a standalone showcase that provides some minimum interaction to:
* load DMN files
* create DMN-related scesim assets, selecting one of the imported DMN.
Currently - RULE/data object model scesim is disabled.
Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset.
Some minimal tests may be done in the following way:
# full compilation (i.e. included GWT compilation) of the runtime module
# open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome
# inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will create a new - empty - scesim file.
Some tricks: to avoid CORS and other policy-related issues:
# set chrome://flags/#allow-insecure-localhost for invalid certificates error
# start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file.
/----/
The "run scenario" functionality won't be implemented by this PR.
All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode
was:
Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor.
>From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`.
Access to it has been "hided" behind a wrapper interface with three actual implementations:
* `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment
* `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment
* `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode).
As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place.
Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach.
Kogito-testing module is a standalone showcase that provides some minimum interaction to:
* load DMN files
* create DMN-related scesim assets, selecting one of the imported DMN.
Currently - RULE/data object model scesim is disabled.
Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset.
Some minimal tests may be done in the following way:
# full compilation (i.e. included GWT compilation) of the runtime module
# open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome
# inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will create a new - empty - scesim file.
Some tricks: to avoid CORS and other policy-related issues:
# set chrome://flags/#allow-insecure-localhost for invalid certificates error
# start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file.
> Create Kogito version of Test Scenarios designer
> ------------------------------------------------
>
> Key: DROOLS-3879
> URL: https://issues.redhat.com/browse/DROOLS-3879
> Project: Drools
> Issue Type: Feature Request
> Components: Scenario Simulation and Testing
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
> Labels: drools-tools
>
> Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor.
> From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`.
> Access to it has been "hided" behind a wrapper interface with three actual implementations:
> * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment
> * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment
> * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode).
> As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place.
> Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach.
> Kogito-testing module is a standalone showcase that provides some minimum interaction to:
> * load DMN files
> * create DMN-related scesim assets, selecting one of the imported DMN.
> Currently - RULE/data object model scesim is disabled.
> Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset.
> Some minimal tests may be done in the following way:
> # full compilation (i.e. included GWT compilation) of the runtime module
> # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome
> # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will create a new - empty - scesim file.
> Some tricks: to avoid CORS and other policy-related issues:
> # set chrome://flags/#allow-insecure-localhost for invalid certificates error
> # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file.
> /----/
> The "run scenario" functionality won't be implemented by this PR.
> All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-3761) [DMN Designer] Data Types - Constraints - Enumeration constraint entry on edit mode - Fix buttons behavior
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-3761?page=com.atlassian.jira.plug... ]
Jozef Marko commented on DROOLS-3761:
-------------------------------------
[~karreiro] sorry, I do not think changing the resolution to *done* is appropriate in situation like this. We did no development to fix the issue. Please revert your changes to jira state. Thank you.
> [DMN Designer] Data Types - Constraints - Enumeration constraint entry on edit mode - Fix buttons behavior
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-3761
> URL: https://issues.redhat.com/browse/DROOLS-3761
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.19.0.Final
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Minor
> Labels: drools-tools
> Attachments: constraint_unsaved.png, focus_lost.webm, lost_focus_data_types.webm
>
>
> The attached video shows the user interaction with enumeration constraint component. We can see if user fill valid values and clicks somewhere outside of the entry in edit mode, the values are lost. The only way how to save values is to click the *check* button. User should not lost filled in values if he clicks outside of input fields.
> Please compare the same behavior with data types list view component. It means [^focus_lost.webm] vs [^lost_focus_data_types.webm] .
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4166) [DMN Designer] Data Types - Shortcuts don't work after the a field is inserted by kebab menu
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-4166?page=com.atlassian.jira.plug... ]
Jozef Marko commented on DROOLS-4166:
-------------------------------------
[~karreiro] sorry, changing jira state to done is not appropriate in case we did no developemnt to fix/implement the jira. Please revert your changes in the jira state. Thank you.
> [DMN Designer] Data Types - Shortcuts don't work after the a field is inserted by kebab menu
> --------------------------------------------------------------------------------------------
>
> Key: DROOLS-4166
> URL: https://issues.redhat.com/browse/DROOLS-4166
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Guilherme Gomes
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
> Fix For: 7.31.0.Final
>
>
> In the Data Types tab, the shortcuts don't work after the a field is inserted by the kebab menu.
> Steps to reproduce:
> - Create a DMN model
> - Select Data Types tab
> - Create a Structure Data Type
> - Save the Data Type
> - Add a nested Data Type by using the kebab menu
> - Type a new name
> - Press Ctrl + S
> Actual result: the parent Data Type is saved (and the changes are lost)
> Expected result: the child Data Type is saved and the changes are save.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months