January 2020 - jboss-jira - Jboss List Archives

[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, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4698: -------------------------------- Description: Support is about both drools/java collections and dmn collections. > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[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, 4 months

1
0
0 / 0

[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. was: Create the *Kogito* versions of scesim editor. No Home Page, no Library, No preferences, no other editors. > 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. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4713) [DMN Designer] Data Types Page is lost

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4713?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4713: ------------------------------------- [~karreiro] sorry, I do not think that changigng state from *can not reproduce* to *done* is appropriate. *done* suggest we did some work to fix an issue, what is not true in this case. Please revert your changes in jira state. > [DMN Designer] Data Types Page is lost > -------------------------------------- > > Key: DROOLS-4713 > URL: https://issues.redhat.com/browse/DROOLS-4713 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > > This issue is caused by DROOLS-4484 > After intensive usage of Drag and Drop feature, the data types was completely lost for all DMN diagrams. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1084) kjar maven dependencies are downloaded even if scope is set to provided or test

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-1084?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-1084: -------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > kjar maven dependencies are downloaded even if scope is set to provided or test > ------------------------------------------------------------------------------- > > Key: DROOLS-1084 > URL: https://issues.redhat.com/browse/DROOLS-1084 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final > Reporter: Lindsay Thurmond > Assignee: Mario Fusco > Priority: Major > Attachments: debug1.png, debug2.png, debug3.png > > > The creation of a new kbase triggers the specified rules kjar to be downloaded from the remote Maven repository. This works as expected but has the side effect of also downloading the Maven dependencies for the kjar. The problem is that it is downloading ALL the Maven dependencies even if they are specified as provided or test scope. This shouldn't happen since provided dependencies are expected to already be on the classpath and we should never need test dependencies at all during runtime at all. > I did some digging into the Drools source to and found out that > {{KieRepositoryImpl#getKieModule()}} > contains logic to check the classpath for the KieModule and if it can't find it to load everything from the Maven repo which includes downloading all the dependencies (and dependencies of dependencies and so on). > Unfortunately the code for checking the classpath is not actually implemented and looks like this: > {code} > private KieModule checkClasspathForKieModule(ReleaseId releaseId) { > // TODO > // ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); > // URL url = classLoader.getResource( ((ReleaseIdImpl)releaseId).getPomPropertiesPath() ); > return null; > } > {code} > After nothing is found on the classpath everything is downloaded from Maven. You can see all the stuff that is going to be downloaded (if it's not already in your Maven repo) in > {{DefaultProjectDependenciesResolver#resolve() //line 159}} > You can even see here that the dependencies have been marked as provided, but regardless they are going to be downloaded. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Mario Fusco edited comment on DROOLS-4909 at 1/8/20 4:35 AM: ------------------------------------------------------------- [~dacr] I just replied to you on DROOLS-4288, I'm pasting my reply below for your convenience bq. Sorry if I'm pointing to something already obvious to you, but it is important that you fully understand the mechanism that prevents this kind of recursion in drools, see https://docs.jboss.org/drools/release/7.31.0.Final/drools-docs/html_singl... bq. In the rule you pasted I don't expect any loop because you're modifying the 'value' property of the Scoring object while the pattern matching on that object doesn't have any constraint referring to that property. bq. I STRONGLY suggest you to provide a complete reproducer of your problem instead of using version 7.20 otherwise you'll have a working application only because you're relying on the side effect of a bug. The rule you pasted clearly doesn't reproduce the issue and in this condition it's impossible for me to further investigate this problem. Please provide an actual reproducer of your problem. Thanks. was (Author: mfusco): [~dacr] I just replied to you on DROOLS-4288, I'm pasting my reply below for your convenience bq. Sorry if I'm pointing to something already obvious to you, but it is important that you fully understand the mechanism that prevents this kind of recursion in drools, see https://docs.jboss.org/drools/release/7.31.0.Final/drools-docs/html_singl... bq. bq. In the rule you pasted I don't expect any loop because you're modifying the 'value' property of the Scoring object while the pattern matching on that object doesn't have any constraint referring to that property. bq. bq. I STRONGLY suggest you to provide a complete reproducer of your problem instead of using version 7.20 otherwise you'll have a working application only because you're relying on the side effect of a bug. The rule you pasted clearly doesn't reproduce the issue and in this condition it's impossible for me to further investigate this problem. Please provide an actual reproducer of your problem. Thanks. > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > 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 > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-4909: -------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > 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 > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Mario Fusco commented on DROOLS-4909: ------------------------------------- [~dacr] I just replied to you on DROOLS-4288, I'm pasting my reply below for your convenience bq. Sorry if I'm pointing to something already obvious to you, but it is important that you fully understand the mechanism that prevents this kind of recursion in drools, see https://docs.jboss.org/drools/release/7.31.0.Final/drools-docs/html_singl... bq. bq. In the rule you pasted I don't expect any loop because you're modifying the 'value' property of the Scoring object while the pattern matching on that object doesn't have any constraint referring to that property. bq. bq. I STRONGLY suggest you to provide a complete reproducer of your problem instead of using version 7.20 otherwise you'll have a working application only because you're relying on the side effect of a bug. The rule you pasted clearly doesn't reproduce the issue and in this condition it's impossible for me to further investigate this problem. Please provide an actual reproducer of your problem. Thanks. > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > 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 > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > 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, 4 months

1
0
0 / 0

[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 if I'm pointing to something already obvious to you, but it is important that you fully understand the mechanism that prevents this kind of recursion in drools, see https://docs.jboss.org/drools/release/7.31.0.Final/drools-docs/html_singl... In the rule you pasted I don't expect any loop because you're modifying the 'value' property of the Scoring object while the pattern matching on that object doesn't have any constraint referring to that property. I STRONGLY suggest you to provide a complete reproducer of your problem instead of using version 7.20 otherwise you'll have a working application only because you're relying on the side effect of a bug. > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David updated DROOLS-4909: ---------------------------------- Description: https://issues.redhat.com/browse/DROOLS-4288 The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example The affected rule looks like : {{rule "reset metric to max score when no more issues are present" //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY when Something($id:identity, $origin:origin) not Issue($id == identity, $origin == origin, category!="metrics") $scoring: Scoring(name == "performance", $id == identity, $origin == origin) then modify($scoring) { setValue(100.0); } end}} ---- from https://issues.redhat.com/browse/DROOLS-4288 : 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`* was: 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`* > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > 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 > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David updated DROOLS-4909: ---------------------------------- Affects Version/s: 7.31.0.Final 7.25.0.Final > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David updated DROOLS-4909: ---------------------------------- Fix Version/s: (was: 7.25.0.Final) > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > 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: Crosson David > Assignee: Mario Fusco > Priority: Major > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

Crosson David created DROOLS-4909: ------------------------------------- Summary: Infinite recursion in drools after version change from v7.20 to v7.21 Key: DROOLS-4909 URL: https://issues.redhat.com/browse/DROOLS-4909 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: Crosson David Assignee: Mario Fusco 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, 4 months

1
0
0 / 0

[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: --------------------------------------- The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final :( (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example :( The affected rule looks like : {{rule "reset metric to max score when no more issues are present" //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY when Something($id:identity, $origin:origin) not Issue($id == identity, $origin == origin, category!="metrics") $scoring: Scoring(name == "performance", $id == identity, $origin == origin) then modify($scoring) { setValue(100.0); } end}} > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4908) [DMN Designer] Improve the Data Types support (7.7)

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4908?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4908: -------------------------------- Description: This is an umbrella for all JIRAs (target to 7.7) related to enhancements on Data Types. (was: This is an umbrella for all JIRAs (target to 7.6) related to enhancements on Data Types. Additional enhancements are tracked under https://issues.redhat.com/browse/DROOLS-4412) > [DMN Designer] Improve the Data Types support (7.7) > --------------------------------------------------- > > Key: DROOLS-4908 > URL: https://issues.redhat.com/browse/DROOLS-4908 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > This is an umbrella for all JIRAs (target to 7.7) related to enhancements on Data Types. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4908) [DMN Designer] Improve the Data Types support (7.7)

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4908?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4908: -------------------------------- Description: This is an umbrella for all JIRAs (target to 7.6) related to enhancements on Data Types. Additional enhancements are tracked under https://issues.redhat.com/browse/DROOLS-4412 was:This is an umbrella for all JIRAs (target to 7.6) related to enhancements on Data Types. > [DMN Designer] Improve the Data Types support (7.7) > --------------------------------------------------- > > Key: DROOLS-4908 > URL: https://issues.redhat.com/browse/DROOLS-4908 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > This is an umbrella for all JIRAs (target to 7.6) related to enhancements on Data Types. > Additional enhancements are tracked under https://issues.redhat.com/browse/DROOLS-4412 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2841) [DMN Designer] Sort item definitions of the model

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-2841?page=com.atlassian.jira.plug... ] Jozef Marko closed DROOLS-2841. ------------------------------- Resolution: Won't Fix The same behavior is now also in Data Object editor. > [DMN Designer] Sort item definitions of the model > ------------------------------------------------- > > Key: DROOLS-2841 > URL: https://issues.redhat.com/browse/DROOLS-2841 > Project: Drools > Issue Type: Task > Components: DMN Editor > Affects Versions: 7.10.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Minor > Labels: drools-tools > > The DMN model file can contain custom item definitions. These are then shown in the data type picker dialog. Currently these definitions are not sorted in the dialog. We should sort them and their attributes alphabetically (a -> z). > Possibility to change key for sorting shouldn't be implemented. If such requirement appears in future, will be implemented in separate jira. > h2. Acceptance Test > - Ordering of {{A a B b C c}} doesn't result to {{A B C a b c}} > - Ordering is applied in properties panel, output data type selectbox > - Ordering is applied in *Manage custom data type* dialog > - Changes in *Manage custom data type* dialog are reflected into > -- *Manage custom data type* dialog > -- output data type selectbox -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1084) kjar maven dependencies are downloaded even if scope is set to provided or test

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-1084?page=com.atlassian.jira.plug... ] Mario Fusco reassigned DROOLS-1084: ----------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > kjar maven dependencies are downloaded even if scope is set to provided or test > ------------------------------------------------------------------------------- > > Key: DROOLS-1084 > URL: https://issues.redhat.com/browse/DROOLS-1084 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final > Reporter: Lindsay Thurmond > Assignee: Mario Fusco > Priority: Major > Attachments: debug1.png, debug2.png, debug3.png > > > The creation of a new kbase triggers the specified rules kjar to be downloaded from the remote Maven repository. This works as expected but has the side effect of also downloading the Maven dependencies for the kjar. The problem is that it is downloading ALL the Maven dependencies even if they are specified as provided or test scope. This shouldn't happen since provided dependencies are expected to already be on the classpath and we should never need test dependencies at all during runtime at all. > I did some digging into the Drools source to and found out that > {{KieRepositoryImpl#getKieModule()}} > contains logic to check the classpath for the KieModule and if it can't find it to load everything from the Maven repo which includes downloading all the dependencies (and dependencies of dependencies and so on). > Unfortunately the code for checking the classpath is not actually implemented and looks like this: > {code} > private KieModule checkClasspathForKieModule(ReleaseId releaseId) { > // TODO > // ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); > // URL url = classLoader.getResource( ((ReleaseIdImpl)releaseId).getPomPropertiesPath() ); > return null; > } > {code} > After nothing is found on the classpath everything is downloaded from Maven. You can see all the stuff that is going to be downloaded (if it's not already in your Maven repo) in > {{DefaultProjectDependenciesResolver#resolve() //line 159}} > You can even see here that the dependencies have been marked as provided, but regardless they are going to be downloaded. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) , Count metrics in wildfly17 does not increase

by alireza alallah (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] alireza alallah commented on WFLY-12941: ---------------------------------------- Only metrics total count does not increase in wildfly 17 metrics > ,Count metrics in wildfly17 does not increase > --------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Reporter: alireza alallah > Assignee: Brian Stansberry > Priority: Major > > Count metrics in wildfly17 does not increase -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) , Count metrics in wildfly17 does not increase

by alireza alallah (Jira)

alireza alallah created WFLY-12941: -------------------------------------- Summary: ,Count metrics in wildfly17 does not increase Key: WFLY-12941 URL: https://issues.redhat.com/browse/WFLY-12941 Project: WildFly Issue Type: Bug Reporter: alireza alallah Assignee: Brian Stansberry Count metrics in wildfly17 does not increase -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12940) Upgrade JBossWS to 5.4.0.Final

by Jim Ma (Jira)

Jim Ma created WFLY-12940: ----------------------------- Summary: Upgrade JBossWS to 5.4.0.Final Key: WFLY-12940 URL: https://issues.redhat.com/browse/WFLY-12940 Project: WildFly Issue Type: Task Components: Web Services Affects Versions: 18.0.1.Final Reporter: Jim Ma Assignee: Jim Ma Fix For: 19.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4791) HttpManagementConstantHeadersTestCase causes tests failures

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4791?page=com.atlassian.jira.plug... ] Brian Stansberry commented on WFCORE-4791: ------------------------------------------ Just a guess. In @After: cli.sendLine("reload --host=master"); That's the only use I see of reloading a host via CLI operation in testsuite/domain. Doing a reload in testsuite/domain is tricky because you need to ensure that not only is the HC reloaded but also that the entire domain is back to a stable state, e.g. slave HCs have reconnected etc. A CLI 'reload' command does not do that. Please reach out to [~yersan] if you need advice on how to handle a reload. > HttpManagementConstantHeadersTestCase causes tests failures > ----------------------------------------------------------- > > Key: WFCORE-4791 > URL: https://issues.redhat.com/browse/WFCORE-4791 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Richard Opalka > Assignee: Tomas Terem > Priority: Major > Fix For: 11.0.0.Beta6 > > Attachments: testsuite.log > > > Commit 68928b0b in WildFly-Core introduced new regression. > High probably test doesn't do proper test environment clean up > and some tests following it are thus failing. The issue isn't visible > in our CI environment so it probably depends on actual tests ordering. > I am able to reproduce this issue on my laptop always. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12722) Upgrade Infinispan to 10.1.0.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12722?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12722: -------------------------------- Summary: Upgrade Infinispan to 10.1.0.Final (was: Upgrade Infinispan to 10.0.1.Final) > Upgrade Infinispan to 10.1.0.Final > ---------------------------------- > > Key: WFLY-12722 > URL: https://issues.redhat.com/browse/WFLY-12722 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 18.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > 10.0.0.Final: https://issues.redhat.com/projects/ISPN/versions/12332894 > 10.1.0.Final: https://issues.redhat.com/projects/ISPN/versions/12342474 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12722) Upgrade Infinispan to 10.0.1.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12722?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12722: -------------------------------- Description: 10.0.0.Final: https://issues.redhat.com/projects/ISPN/versions/12332894 10.1.0.Final: https://issues.redhat.com/projects/ISPN/versions/12342474 was:https://issues.jboss.org/projects/ISPN/versions/12332894 > Upgrade Infinispan to 10.0.1.Final > ---------------------------------- > > Key: WFLY-12722 > URL: https://issues.redhat.com/browse/WFLY-12722 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 18.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > 10.0.0.Final: https://issues.redhat.com/projects/ISPN/versions/12332894 > 10.1.0.Final: https://issues.redhat.com/projects/ISPN/versions/12342474 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1700) Intermittently failing AttributeMappingSuiteChild

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1700?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1700: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Intermittently failing AttributeMappingSuiteChild > ------------------------------------------------- > > Key: ELY-1700 > URL: https://issues.redhat.com/browse/ELY-1700 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.7.0.CR2 > Reporter: Martin Choma > Priority: Minor > Fix For: 1.11.0.CR6 > > > With ration 1:1000 we see ELY01125: Ldap-backed realm failed to obtain context. > {noformat} > org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:215) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622) > at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77) > at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33) > at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218) > Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms. > at com.sun.jndi.ldap.Connection.readReply(Connection.java:507) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > 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.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355) > at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203) > ... 7 more > {noformat} > {noformat} > 00:29:39,451 TRACE (main) [org.wildfly.security] <SecurityDomain.java:1036> Building security domain with defaultRealmName default. > 00:29:39,452 TRACE (main) [org.wildfly.security] <SecurityDomain.java:708> Role mapping: principal [anonymous] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 00:29:39,452 TRACE (main) [org.wildfly.security] <ServerAuthenticationContext.java:1163> Principal assigning: [userWithAttributes], pre-realm rewritten: [userWithAttributes], realm name: [default], post-realm rewritten: [userWithAttributes], realm rewritten: [userWithAttributes] > 00:29:39,453 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:189> Obtaining lock for identity [userWithAttributes]... > 00:29:39,454 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:197> Obtained lock for identity [userWithAttributes]. > 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:427> Creating [class javax.naming.directory.InitialDirContext] with environment: > 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.credentials] with value [******] > 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.ldap.factory.socket] with value [org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory] > 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.authentication] with value [simple] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.provider.url] with value [ldap://localhost:11390/] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.read.timeout] with value [60000] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.connect.timeout] with value [5000] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.principal] with value [uid=server,dc=elytron,dc=wildfly,dc=org] > 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.referral] with value [ignore] > 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory] > 00:29:44,528 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:438> Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms. > at com.sun.jndi.ldap.Connection.readReply(Connection.java:507) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > 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.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355) > at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622) > at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77) > at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162) > at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71) > at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > 00:29:44,529 INFO (pool-3-thread-2) [org.apache.directory.server.ldap.handlers.LdapRequestHandler] <LdapRequestHandler.java:131> ignoring the message Abandon Request : > Message Id : 1org.apache.directory.api.ldap.model.message.AbandonRequestImpl@8444b052 received from null session > {noformat} > Maybe just to try prolong SimpleDirContextFactoryBuilder#DEFAULT_CONNECT_TIMEOUT [1] > This issue occurs also with ELY-1699. It is very probable machine was slow. But it would be fine if testsuite could cope with this situation as well. > > [1] https://github.com/wildfly-security/wildfly-elytron/blob/38e1e01972414ad7... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1723) Separate auth client parsing from the API.

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1723?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1723: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Separate auth client parsing from the API. > ------------------------------------------ > > Key: ELY-1723 > URL: https://issues.redhat.com/browse/ELY-1723 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Blocker > Fix For: 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1687?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1687: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Initial WildFly Elytron Performance Enhancments > ----------------------------------------------- > > Key: ELY-1687 > URL: https://issues.redhat.com/browse/ELY-1687 > Project: WildFly Elytron > Issue Type: Task > Affects Versions: 1.7.0.CR2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR6 > > Attachments: BASIC_Auth_Load.jmx, Flight.tgz > > > Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues. > After that we will perform the initial metric test again and close the issue. > A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test. > The first test is to test HTTP Basic authentication backed by WildFly Elytron. > * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate. > Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes. > h2. Initial Issues > h3. WildFlyElytronProvider Locking > Total block time 8.393s via calls to java.security.Provider.getServices(); > Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance. > h3. Memory 2.42G of char[] > e.g. > {noformat} > void java.nio.HeapCharBuffer.<init>(int, int) 13037 > CharBuffer java.nio.CharBuffer.allocate(int) 9148 > CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148 > CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148 > {noformat} > Is there any option to re-use these as they can be cleared instead of leaving to GC. > HeapByteBuffer and HeapCharBuffer are also quite prominent. > h3. Memory 1.78G of Callback[] > Using the CallbackHandler API the use of the array is inevitable. > * Could we extend the API to avoid the array? > * Could we re-use the array? Could consider null termination. > {noformat} > boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222 > {noformat} > h3. Memory 1.41G of HttpAuthenticator$Builder > {noformat} > HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699 > boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699 > {noformat} > Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use? > h3. Memory 1.3G of SecurityContextImpl > {noformat} > SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247 > SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673 > {noformat} > Also instances of HttpAuthenticator > {noformat} > HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624 > {noformat} > And instances of HttpAuthenticator$AuthenticationExchange. > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423 > {noformat} > As with HttpAuthenticator$Builder is there any way to consider re-use? > h3. Memory 1.21G of java.util.ArrayList > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911 > {noformat} > Can check the use and see if an alternative is possible. > _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._ > _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._ > https://issues.jboss.org/browse/ELY-1689 > h3. Memory ServerAuthenticationContext States > Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states. > Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance? > h3. Memory SecurityIdentity > As an immutable object we can end up with intermediate throw away instances, can we optimise create once? > {noformat} > SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454 > ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454 > {noformat} > h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator > These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages. > Could a static Base64 conversion clean up a lot of this? > h1. Done > h3. Method Profiling - new HttpString > A lot of time spend creating new HttpString (Package is no3 in the top list) > {noformat} > void io.undertow.util.HttpString.<init>(String) 4 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4 > {noformat} > Could we re-use the HttpString for common header types? > Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25 > h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[] > {noformat} > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091 > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091 > {noformat} > This test did not use forms at all, is this something that can be delayed until we know it is needed? > _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._ > https://issues.jboss.org/browse/ELYWEB-27 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1682: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.redhat.com/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Major > Fix For: 1.11.0.CR6 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1440: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1440 > URL: https://issues.redhat.com/browse/ELY-1440 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR6 > > > This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event. > Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance. > At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-533?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-533: --------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.redhat.com/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR6 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-243) Ensure reference to repository is removed from pom

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-243?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-243: --------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Ensure reference to repository is removed from pom > -------------------------------------------------- > > Key: ELY-243 > URL: https://issues.redhat.com/browse/ELY-243 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR6 > > > We need to ensure the reference to the JBoss repo is removed from the pom and artefacts are available from Maven Central. > Also at this point probably good to put the steps in place for Elytron to also be available from Maven Central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1726) Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest`

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1726?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1726: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest` > --------------------------------------------------------------------------------------- > > Key: ELY-1726 > URL: https://issues.redhat.com/browse/ELY-1726 > Project: WildFly Elytron > Issue Type: Task > Components: Credentials > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR6 > > > This was introduced in the following PR https://github.com/wildfly-security-incubator/wildfly-elytron/pull/54 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1724) Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1724?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1724: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ----------------------------------------------------------------------------------------- > > Key: ELY-1724 > URL: https://issues.redhat.com/browse/ELY-1724 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Critical > Fix For: 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1744) Remove use of java.security.acl APIs

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1744?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1744: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Remove use of java.security.acl APIs > ------------------------------------ > > Key: ELY-1744 > URL: https://issues.redhat.com/browse/ELY-1744 > Project: WildFly Elytron > Issue Type: Task > Components: Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR6 > > > The 'java.security.acls' packages has been deprecated and flagged for removal, this will be removed in Java 13 > https://bugs.openjdk.java.net/browse/JDK-8191138 > Within WildFly Elytron we only seem to use it in the JAAS security realm which I don't believe is used although likely is public API. I believe the use was to mirror some PicketBox behaviour. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1742) Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1742?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1742: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API > ---------------------------------------------------------------------------------------------------- > > Key: ELY-1742 > URL: https://issues.redhat.com/browse/ELY-1742 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1741) Clean up the 'wildfly-elytron-x500' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1741?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1741: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Clean up the 'wildfly-elytron-x500' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------- > > Key: ELY-1741 > URL: https://issues.redhat.com/browse/ELY-1741 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1740) Clean up the 'wildfly-elytron-sasl' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1740?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1740: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Clean up the 'wildfly-elytron-sasl' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------- > > Key: ELY-1740 > URL: https://issues.redhat.com/browse/ELY-1740 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1739) Clean up the 'wildfly-elytron-jaspi' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1739?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1739: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Clean up the 'wildfly-elytron-jaspi' module as it currently contains both public and private API > ------------------------------------------------------------------------------------------------ > > Key: ELY-1739 > URL: https://issues.redhat.com/browse/ELY-1739 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1737) Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1737?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1737: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1737 > URL: https://issues.redhat.com/browse/ELY-1737 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1735) Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1735?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1735: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1735 > URL: https://issues.redhat.com/browse/ELY-1735 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1749) Code review of WildFlyElytronProvider

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1749?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1749: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Code review of WildFlyElytronProvider > ------------------------------------- > > Key: ELY-1749 > URL: https://issues.redhat.com/browse/ELY-1749 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1842) Update the tool to support generating and exporting / importing a secret key to the credential store

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1842?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1842: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Update the tool to support generating and exporting / importing a secret key to the credential store > ---------------------------------------------------------------------------------------------------- > > Key: ELY-1842 > URL: https://issues.redhat.com/browse/ELY-1842 > Project: WildFly Elytron > Issue Type: Requirement > Components: Command-Line Tool, Credential Store > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR6 > > > In general the following options should be supported: - > * `--generate-secret-key` > * `--export-secret-key` > * `--import-secret-key` -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1745) The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration.

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1745?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1745: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1745 > URL: https://issues.redhat.com/browse/ELY-1745 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR6 > > > The NPE is due to the following code: - > {noformat} > } else if (callback instanceof AvailableRealmsCallback) { > Collection<String> names = stateRef.get().getMechanismConfiguration().getMechanismRealmNames(); > if (log.isTraceEnabled()) { > log.tracef("Handling AvailableRealmsCallback: realms = [%s]", String.join(", ", names)); > } > if (! names.isEmpty()) { > ((AvailableRealmsCallback) callback).setRealmNames(names.toArray(new String[names.size()])); > } > handleOne(callbacks, idx + 1); > {noformat} > If mechanism configuration is mandatory this should report an appropriate error, if not it should fallback to specifying an empty list. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1809) Update JAPICMP on a module by module basis

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1809?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1809: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Update JAPICMP on a module by module basis > ------------------------------------------ > > Key: ELY-1809 > URL: https://issues.redhat.com/browse/ELY-1809 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.11.0.CR6 > > > Each module should test it's own compatibility - however the compatible version should likely be defined in the root pom. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1808) Undertake further review of all duplicate packages to ensure we can make unique

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1808?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1808: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Undertake further review of all duplicate packages to ensure we can make unique > ------------------------------------------------------------------------------- > > Key: ELY-1808 > URL: https://issues.redhat.com/browse/ELY-1808 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.11.0.CR6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1778) Enhanced Audit Logging - Feature parity with legacy audit logging

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1778?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1778: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Enhanced Audit Logging - Feature parity with legacy audit logging > ----------------------------------------------------------------- > > Key: ELY-1778 > URL: https://issues.redhat.com/browse/ELY-1778 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Audit > Reporter: Justin Cook > Priority: Major > Fix For: 1.11.0.CR6 > > > This RFE for Enhanced Audit Logging in WildFly Elytron is for feature parity with legacy audit logging via: > * Additional audit events > * An "Audit" annotation -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1765) Review authentication client dependencies on credential sources

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1765?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1765: ---------------------------- Fix Version/s: 1.11.0.CR6 (was: 1.11.0.CR5) > Review authentication client dependencies on credential sources > --------------------------------------------------------------- > > Key: ELY-1765 > URL: https://issues.redhat.com/browse/ELY-1765 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.11.0.CR6 > > > Could these credential sources be discoverable from java.security.Provider with a more generic configuration API? This could help break any dependency from authentication client to the implementation. > _In the opposite direction I think it is Ok for the impl to depend on the client._ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1918) Release WildFly Elytron 1.11.0.CR5

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1918?page=com.atlassian.jira.plugin.... ] Farah Juma resolved ELY-1918. ----------------------------- Resolution: Done > Release WildFly Elytron 1.11.0.CR5 > ---------------------------------- > > Key: ELY-1918 > URL: https://issues.redhat.com/browse/ELY-1918 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.11.0.CR5 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-86) Release Elytron Web 1.7.0.CR4

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELYWEB-86?page=com.atlassian.jira.plugin... ] Farah Juma resolved ELYWEB-86. ------------------------------ Resolution: Done > Release Elytron Web 1.7.0.CR4 > ----------------------------- > > Key: ELYWEB-86 > URL: https://issues.redhat.com/browse/ELYWEB-86 > Project: Elytron Web > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.7.0.CR4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-85) Upgrade WildFly Elytron to 1.11.0.CR5

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELYWEB-85?page=com.atlassian.jira.plugin... ] Farah Juma resolved ELYWEB-85. ------------------------------ Resolution: Done > Upgrade WildFly Elytron to 1.11.0.CR5 > ------------------------------------- > > Key: ELYWEB-85 > URL: https://issues.redhat.com/browse/ELYWEB-85 > Project: Elytron Web > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.7.0.CR4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4794) Upgrade Elytron Web to 1.7.0.CR4

by Farah Juma (Jira)

Farah Juma created WFCORE-4794: ---------------------------------- Summary: Upgrade Elytron Web to 1.7.0.CR4 Key: WFCORE-4794 URL: https://issues.redhat.com/browse/WFCORE-4794 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma Fix For: 11.0.0.Beta6 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4793) Upgrade WildFly Elytron to 1.11.0.CR5

by Farah Juma (Jira)

Farah Juma created WFCORE-4793: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.11.0.CR5 Key: WFCORE-4793 URL: https://issues.redhat.com/browse/WFCORE-4793 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma Fix For: 11.0.0.Beta6 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-12486: --------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/12836, https://github.com/wildfly/wildfly/pull/12878 (was: https://github.com/wildfly/wildfly/pull/12836) > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Fix For: 19.0.0.Beta1 > > Attachments: memory-leak-bad.png, memory-leak-good.png, wildfly-thread-leak.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12939) Local scheduler should trigger expiration *after* distributed web session/SFSB has expired.

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12939: ----------------------------------- Summary: Local scheduler should trigger expiration *after* distributed web session/SFSB has expired. Key: WFLY-12939 URL: https://issues.redhat.com/browse/WFLY-12939 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro The expiration scheduler schedules a task to expire a web sesssion/SFSB using the last modified time + the max inactive interval (or @StatefulTimeout). However, technically, the session/bean is not expired until after this time. This off-by-one bug can cause the expiration task to determine that the session is not yet expired and thus can result in delayed expiration of a session. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-86) Release Elytron Web 1.7.0.CR4

by Farah Juma (Jira)

Farah Juma created ELYWEB-86: -------------------------------- Summary: Release Elytron Web 1.7.0.CR4 Key: ELYWEB-86 URL: https://issues.redhat.com/browse/ELYWEB-86 Project: Elytron Web Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.7.0.CR4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-85) Upgrade WildFly Elytron to 1.11.0.CR5

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELYWEB-85?page=com.atlassian.jira.plugin... ] Farah Juma updated ELYWEB-85: ----------------------------- Fix Version/s: 1.7.0.CR4 > Upgrade WildFly Elytron to 1.11.0.CR5 > ------------------------------------- > > Key: ELYWEB-85 > URL: https://issues.redhat.com/browse/ELYWEB-85 > Project: Elytron Web > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.7.0.CR4 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-85) Upgrade WildFly Elytron to 1.11.0.CR5

by Farah Juma (Jira)

Farah Juma created ELYWEB-85: -------------------------------- Summary: Upgrade WildFly Elytron to 1.11.0.CR5 Key: ELYWEB-85 URL: https://issues.redhat.com/browse/ELYWEB-85 Project: Elytron Web Issue Type: Component Upgrade Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1754) Update test for JDK cipher suites cover when TLS 1.3 support is added

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1754?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1754: ---------------------------- Fix Version/s: 1.11.0.CR5 > Update test for JDK cipher suites cover when TLS 1.3 support is added > --------------------------------------------------------------------- > > Key: ELY-1754 > URL: https://issues.redhat.com/browse/ELY-1754 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Diana Vilkolakova > Assignee: Farah Juma > Priority: Major > Fix For: 1.11.0.CR5 > > > Elytron testsuite contains test whether Mechanism Database covers all cipher suites from JDK. Currently we are excluding testing for cipher suites from TLS 1.3. After the support of TLS 1.3 is added, this test should be updated. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1918) Release WildFly Elytron 1.11.0.CR5

by Farah Juma (Jira)

Farah Juma created ELY-1918: ------------------------------- Summary: Release WildFly Elytron 1.11.0.CR5 Key: ELY-1918 URL: https://issues.redhat.com/browse/ELY-1918 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.11.0.CR5 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12938) Expired distributed web sessions/SFSBs not properly removed following topology change with no rehash

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12938: ----------------------------------- Summary: Expired distributed web sessions/SFSBs not properly removed following topology change with no rehash Key: WFLY-12938 URL: https://issues.redhat.com/browse/WFLY-12938 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro On topology change, changes to primary session ownership determine when a given member should schedule expiration of a given session, or cancel a scheduled expiration of a previously owned session. Primary ownership is determined by 2 components: the key partitioner and a consistent hash. The key partitioner determines which the segment to which a given key is assigned. A consistent hash determines which member is the primary owner of a given segment. Rescheduling of session expiration is triggered from a data rehash event. However, when the second to last member leaves the cluster, there is no data rehash event, thus expired session owned by the leaving member are never removed. To fix this, we must also trigger rescheduling of expiration in the event of a topology change where no rehashing occurs. This results in expired web sessions/SFSBs remaining in memory, potentially indefinitely. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4907) DMN FunctionDefinition parameter not trimmed by editor

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4907?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4907: ----------------------------------- Labels: drools-tools (was: ) > DMN FunctionDefinition parameter not trimmed by editor > ------------------------------------------------------ > > Key: DROOLS-4907 > URL: https://issues.redhat.com/browse/DROOLS-4907 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: image-2020-01-07-17-19-25-638.png > > > Parameter are not trimmed by the editor > !image-2020-01-07-17-19-25-638.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4907) DMN FunctionDefinition parameter not trimmed by editor

by Michael Anstis (Jira)

[ https://issues.redhat.com/browse/DROOLS-4907?page=com.atlassian.jira.plug... ] Michael Anstis updated DROOLS-4907: ----------------------------------- Story Points: 3 Sprint: 2020 Week 01-03 (from Dec 30) > DMN FunctionDefinition parameter not trimmed by editor > ------------------------------------------------------ > > Key: DROOLS-4907 > URL: https://issues.redhat.com/browse/DROOLS-4907 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Matteo Mortari > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > Attachments: image-2020-01-07-17-19-25-638.png > > > Parameter are not trimmed by the editor > !image-2020-01-07-17-19-25-638.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1047) Kiali Validations sync-up

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1047?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1047: --------------------------------------- TODO: Port name must follow <protocol>[-suffix] form Deployment exposing same port as Service not found > Kiali Validations sync-up > ------------------------- > > Key: SWSQE-1047 > URL: https://issues.redhat.com/browse/SWSQE-1047 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > Check all actual validations in https://kiali.io/documentation/validations/ > Sync up in Polarion testcases. > UI Automations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4713) [DMN Designer] Data Types Page is lost

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4713?page=com.atlassian.jira.plug... ] Guilherme Gomes closed DROOLS-4713. ----------------------------------- Resolution: Done > [DMN Designer] Data Types Page is lost > -------------------------------------- > > Key: DROOLS-4713 > URL: https://issues.redhat.com/browse/DROOLS-4713 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > > This issue is caused by DROOLS-4484 > After intensive usage of Drag and Drop feature, the data types was completely lost for all DMN diagrams. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4056) DMN Editor: Keyboard shortcut functionality on mouse initiated focus.

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4056?page=com.atlassian.jira.plug... ] Guilherme Gomes closed DROOLS-4056. ----------------------------------- Resolution: Done > DMN Editor: Keyboard shortcut functionality on mouse initiated focus. > --------------------------------------------------------------------- > > Key: DROOLS-4056 > URL: https://issues.redhat.com/browse/DROOLS-4056 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Daniel José dos Santos > Priority: Major > Labels: Field, FieldEnablementFeedback, UX, drools-tools > Attachments: ctrls.gif > > > Keyboard shortcut works only when arrow keys are used to focus on the DMN type element. If the user start editing a field with mouse and type "CTRL-S" to save it, the shortcut does not work. > Note: Team invested CTRL-S, but there was some potential conflict with built in browser controls. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4056) DMN Editor: Keyboard shortcut functionality on mouse initiated focus.

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4056?page=com.atlassian.jira.plug... ] Guilherme Gomes reopened DROOLS-4056: ------------------------------------- > DMN Editor: Keyboard shortcut functionality on mouse initiated focus. > --------------------------------------------------------------------- > > Key: DROOLS-4056 > URL: https://issues.redhat.com/browse/DROOLS-4056 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: Daniel José dos Santos > Priority: Major > Labels: Field, FieldEnablementFeedback, UX, drools-tools > Attachments: ctrls.gif > > > Keyboard shortcut works only when arrow keys are used to focus on the DMN type element. If the user start editing a field with mouse and type "CTRL-S" to save it, the shortcut does not work. > Note: Team invested CTRL-S, but there was some potential conflict with built in browser controls. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4713) [DMN Designer] Data Types Page is lost

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4713?page=com.atlassian.jira.plug... ] Guilherme Gomes reopened DROOLS-4713: ------------------------------------- > [DMN Designer] Data Types Page is lost > -------------------------------------- > > Key: DROOLS-4713 > URL: https://issues.redhat.com/browse/DROOLS-4713 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.30.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Critical > Labels: drools-tools > > This issue is caused by DROOLS-4484 > After intensive usage of Drag and Drop feature, the data types was completely lost for all DMN diagrams. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4166) [DMN Designer] Data Types - Shortcuts don't work after the a field is inserted by kebab menu

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4166?page=com.atlassian.jira.plug... ] Guilherme Gomes reopened DROOLS-4166: ------------------------------------- > [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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3761) [DMN Designer] Data Types - Constraints - Enumeration constraint entry on edit mode - Fix buttons behavior

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-3761?page=com.atlassian.jira.plug... ] Guilherme Gomes closed DROOLS-3761. ----------------------------------- Resolution: Done > [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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3761) [DMN Designer] Data Types - Constraints - Enumeration constraint entry on edit mode - Fix buttons behavior

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-3761?page=com.atlassian.jira.plug... ] Guilherme Gomes reopened DROOLS-3761: ------------------------------------- > [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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4166) [DMN Designer] Data Types - Shortcuts don't work after the a field is inserted by kebab menu

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4166?page=com.atlassian.jira.plug... ] Guilherme Gomes closed DROOLS-4166. ----------------------------------- Resolution: Done > [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, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4908) [DMN Designer] Improve the Data Types support (7.7)

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4908?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4908: ------------------------------------ Epic Name: [DMN Designer] Improve the Data Types support (7.7) (was: [DMN Designer] Improve the Data Types support (7.6)) > [DMN Designer] Improve the Data Types support (7.7) > --------------------------------------------------- > > Key: DROOLS-4908 > URL: https://issues.redhat.com/browse/DROOLS-4908 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > This is an umbrella for all JIRAs (target to 7.6) related to enhancements on Data Types. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12937) Expired distributed web sessions/SFSBs not properly removed following rehash

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12937: ----------------------------------- Summary: Expired distributed web sessions/SFSBs not properly removed following rehash Key: WFLY-12937 URL: https://issues.redhat.com/browse/WFLY-12937 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro On topology change, changes to primary session ownership determine when a given member should schedule expiration of a given session, or cancel a scheduled expiration of a previously owned session. Primary ownership is determined by 2 components: the key partitioner and a consistent hash. The key partitioner determines which the segment to which a given key is assigned. A consistent hash determines which member is the primary owner of a given segment. The logic for determining primary ownership changes currently uses the wrong key partitioner. Currently, we use the partitioner from the cache configuration. However, when grouping is enabled (which is the case for web sessions and SFSBs), this parititioner is wrapped by a GroupPartitioner at runtime. That is the one we need. This results in expired web sessions/SFSBs remaining in memory, potentially indefinitely. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1997) Bundler: find new default bundler

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-1997?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-1997: -------------------------------- Also imvestigate whether JCTools [1] can help (impl of lockless MPMC,SPMC queues). [1] https://github.com/JCTools/JCTools > Bundler: find new default bundler > --------------------------------- > > Key: JGRP-1997 > URL: https://issues.redhat.com/browse/JGRP-1997 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 5.1 > > > Before removing the deprecated sender-sends-with-timer bundler, assess which bundler is the fastest across a range of applications (UPerf, Infinispan etc). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4908) [DMN Designer] Improve the Data Types support (7.7)

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4908?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4908: ------------------------------------ Summary: [DMN Designer] Improve the Data Types support (7.7) (was: [DMN Designer] Improve the Data Types support (7.6)) > [DMN Designer] Improve the Data Types support (7.7) > --------------------------------------------------- > > Key: DROOLS-4908 > URL: https://issues.redhat.com/browse/DROOLS-4908 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > This is an umbrella for all JIRAs (target to 7.6) related to enhancements on Data Types. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4879) [DMN Designer] unification of import flash messages

by Daniel José dos Santos (Jira)

[ https://issues.redhat.com/browse/DROOLS-4879?page=com.atlassian.jira.plug... ] Daniel José dos Santos commented on DROOLS-4879: ------------------------------------------------ Yes, thank you, [~jomarko] > [DMN Designer] unification of import flash messages > --------------------------------------------------- > > Key: DROOLS-4879 > URL: https://issues.redhat.com/browse/DROOLS-4879 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.32.0.Final > Reporter: Jozef Marko > Assignee: Daniel José dos Santos > Priority: Major > Labels: drools-tools > > We should unify the flash messages related to import data types. See the github comment here https://github.com/kiegroup/kie-wb-common/pull/3071#issuecomment-566436373 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4908) [DMN Designer] Improve the Data Types support (7.6)

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4908: --------------------------------------- Summary: [DMN Designer] Improve the Data Types support (7.6) Key: DROOLS-4908 URL: https://issues.redhat.com/browse/DROOLS-4908 Project: Drools Issue Type: Epic Components: DMN Editor Reporter: Guilherme Gomes Assignee: Guilherme Gomes This is an umbrella for all JIRAs (target to 7.6) related to enhancements on Data Types. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4906) Maven configuration script is not able to start in HA-CEP image in Openshift

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4906?page=com.atlassian.jira.plug... ] Massimiliano Dessi updated DROOLS-4906: --------------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > Maven configuration script is not able to start in HA-CEP image in Openshift > ---------------------------------------------------------------------------- > > Key: DROOLS-4906 > URL: https://issues.redhat.com/browse/DROOLS-4906 > Project: Drools > Issue Type: Bug > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Blocker > Labels: HADrools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4555) functionDefinition parameter with trailing space causes NPE

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4555?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4555: ----------------------------------- Tester: Tibor Zimanyi Story Points: 2 Sprint: 2020 Week 01-03 (from Dec 30) > functionDefinition parameter with trailing space causes NPE > ----------------------------------------------------------- > > Key: DROOLS-4555 > URL: https://issues.redhat.com/browse/DROOLS-4555 > Project: Drools > Issue Type: Bug > Reporter: Jonas Tamimi > Assignee: Matteo Mortari > Priority: Major > > Hi, > this is my first issue, so I hope I did everything right. We have been using version 7.21.0.Final of Drools for the last few months. A few weeks ago we switched to the latest version and could not import a few of our decision models (.dmn) anymore. According to our own research the bug seems to be present since 7.22.0.t042 and is still present in the latest snapshot. > This is the relevant logging output: [https://gist.github.com/oas/ec0f70585411d8c3f0266b7d2fd02ebc|https://gist...] > I tried to narrow down the exception and it seems to be in the method {{checkVariableName}} of {{org.kie.dmn.feel.parser.feel11.FEELParser}}. {{errorChecker.hasErrors()}} is false, but it is not catched by the if statement in line 111. Because of this, {{errorChecker.getErrors()}} returns null instead of a {{List<FEELEvent>}}. > The method {{checkVariableName}} in {{org.kie.dmn.core.compiler.DMNCompilerHelper}}, assumes that a list will be returned and calls {{isEmpty()}}. This throws the {{NullPointerException}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4903) In constraints fail to compile if negated or inside a forall pattern

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4903?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-4903. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/9ac0e309d716606c8b07085386d13fd... > In constraints fail to compile if negated or inside a forall pattern > -------------------------------------------------------------------- > > Key: DROOLS-4903 > URL: https://issues.redhat.com/browse/DROOLS-4903 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.31.0.Final > Reporter: Matteo Casalino > Assignee: Mario Fusco > Priority: Major > Attachments: in-constraint-negation.tgz > > > It appears that the KieBuilder fails to compile the following pattern: > {noformat} > Pojo(!(x in (1,2,3))) > {noformat} > returning the following error: > {noformat} > Error Messages: > Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules.drl, line=4, column=0 > text=Unable to Analyse Expression !(x in (1,2,3)): > [Error: unexpected token: ,2] > [Near : {... !(x in (1,2,3)) ....}] > {noformat} > Furthermore, as of Drools 7.29.0.Final, the following form will also fail to compile: > {noformat} > forall(Pojo(y==42, x in (1,2,3))) > {noformat} > with the following error: > {noformat} > Error Messages: > Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules.drl, line=4, column=0 > text=Unable to Analyse Expression !(y==42) || !(x in (1,2,3)): > [Error: unexpected token: ,2] > [Near : {... !(y==42) || !(x in (1,2,3)) ....}] > {noformat} > The latter is likely a consequence of the negation introduced by [DROOLS-4632], [DROOLS-4633] -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1049) install-ocp to support OCP 4.4

by Matthew Mahoney (Jira)

Matthew Mahoney created SWSQE-1049: -------------------------------------- Summary: install-ocp to support OCP 4.4 Key: SWSQE-1049 URL: https://issues.redhat.com/browse/SWSQE-1049 Project: Kiali QE Issue Type: QE Task Reporter: Matthew Mahoney Assignee: Filip Brychta OCP 4.4 clusters will need to be created. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4555) functionDefinition parameter with trailing space causes NPE

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4555?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-4555: ----------------------------------- Summary: functionDefinition parameter with trailing space causes NPE (was: Importing DMN model causes NullPointerException) > functionDefinition parameter with trailing space causes NPE > ----------------------------------------------------------- > > Key: DROOLS-4555 > URL: https://issues.redhat.com/browse/DROOLS-4555 > Project: Drools > Issue Type: Bug > Reporter: Jonas Tamimi > Assignee: Matteo Mortari > Priority: Major > > Hi, > this is my first issue, so I hope I did everything right. We have been using version 7.21.0.Final of Drools for the last few months. A few weeks ago we switched to the latest version and could not import a few of our decision models (.dmn) anymore. According to our own research the bug seems to be present since 7.22.0.t042 and is still present in the latest snapshot. > This is the relevant logging output: [https://gist.github.com/oas/ec0f70585411d8c3f0266b7d2fd02ebc|https://gist...] > I tried to narrow down the exception and it seems to be in the method {{checkVariableName}} of {{org.kie.dmn.feel.parser.feel11.FEELParser}}. {{errorChecker.hasErrors()}} is false, but it is not catched by the if statement in line 111. Because of this, {{errorChecker.getErrors()}} returns null instead of a {{List<FEELEvent>}}. > The method {{checkVariableName}} in {{org.kie.dmn.core.compiler.DMNCompilerHelper}}, assumes that a list will be returned and calls {{isEmpty()}}. This throws the {{NullPointerException}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4907) DMN FunctionDefinition parameter not trimmed by editor

by Matteo Mortari (Jira)

Matteo Mortari created DROOLS-4907: -------------------------------------- Summary: DMN FunctionDefinition parameter not trimmed by editor Key: DROOLS-4907 URL: https://issues.redhat.com/browse/DROOLS-4907 Project: Drools Issue Type: Enhancement Components: DMN Editor Reporter: Matteo Mortari Assignee: Michael Anstis Attachments: image-2020-01-07-17-19-25-638.png Parameter are not trimmed by the editor !image-2020-01-07-17-19-25-638.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Data types are editable in readonly mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-3292: ------------------------------------- [~karreiro] sorry, I think we can not. I updated the description of the jira. Let me know if you need more details. > [DMN Designer] Data types are editable in readonly mode > ------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attached screenshot is shown enabled data types even the dmn editor is in readonly mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Data types are editable in readonly mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-3292: -------------------------------- Description: In the attached screenshot is shown enabled data types even the dmn editor is in readonly mode. (was: In the attachment is shown manage button is not disabled in read only mode. ) > [DMN Designer] Data types are editable in readonly mode > ------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attached screenshot is shown enabled data types even the dmn editor is in readonly mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Data types are editable in readonly mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-3292: -------------------------------- Attachment: (was: Screenshot from 2018-11-09 09-25-38.png) > [DMN Designer] Data types are editable in readonly mode > ------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attachment is shown manage button is not disabled in read only mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Data types are editable in readonly mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-3292: -------------------------------- Steps to Reproduce: - Open a dmn diagram - Click on its version selector - Pick some older version of diagram - Graph editor will be in readonly mode - Navigate do data types editor -- It will be not in read only mode -- it should be in readonly mode was: - Open older version of some dmn diagram - Select an Decision node - Expand properties panel - Click on Manage button -- Currently data type dialog is shown -- No action should be taken > [DMN Designer] Data types are editable in readonly mode > ------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attachment is shown manage button is not disabled in read only mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Data types are editable in readonly mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-3292: -------------------------------- Priority: Major (was: Trivial) > [DMN Designer] Data types are editable in readonly mode > ------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attachment is shown manage button is not disabled in read only mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Data types are editable in readonly mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-3292: -------------------------------- Affects Version/s: 7.31.0.Final > [DMN Designer] Data types are editable in readonly mode > ------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attachment is shown manage button is not disabled in read only mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Data types are editable in readonly mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-3292: -------------------------------- Summary: [DMN Designer] Data types are editable in readonly mode (was: [DMN Designer] Custom Data Type dialog can be invoked from read only mode) > [DMN Designer] Data types are editable in readonly mode > ------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Trivial > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attachment is shown manage button is not disabled in read only mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3292) [DMN Designer] Custom Data Type dialog can be invoked from read only mode

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-3292?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-3292: -------------------------------- Attachment: Screenshot from 2020-01-07 17-00-12.png > [DMN Designer] Custom Data Type dialog can be invoked from read only mode > ------------------------------------------------------------------------- > > Key: DROOLS-3292 > URL: https://issues.redhat.com/browse/DROOLS-3292 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.14.0.Final, 7.31.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Gomes > Priority: Trivial > Labels: drools-tools > Attachments: Screenshot from 2020-01-07 17-00-12.png > > > In the attachment is shown manage button is not disabled in read only mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4555) Importing DMN model causes NullPointerException

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-4555?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-4555: ---------------------------------------- Hi [~jooas] and sorry for the late reply. Do you have an example DMN model you can share to reproduce the issue, please? This would avoid a blind fix which may not fully solve the issue you are experiencing. > Importing DMN model causes NullPointerException > ----------------------------------------------- > > Key: DROOLS-4555 > URL: https://issues.redhat.com/browse/DROOLS-4555 > Project: Drools > Issue Type: Bug > Reporter: Jonas Tamimi > Assignee: Matteo Mortari > Priority: Major > > Hi, > this is my first issue, so I hope I did everything right. We have been using version 7.21.0.Final of Drools for the last few months. A few weeks ago we switched to the latest version and could not import a few of our decision models (.dmn) anymore. According to our own research the bug seems to be present since 7.22.0.t042 and is still present in the latest snapshot. > This is the relevant logging output: [https://gist.github.com/oas/ec0f70585411d8c3f0266b7d2fd02ebc|https://gist...] > I tried to narrow down the exception and it seems to be in the method {{checkVariableName}} of {{org.kie.dmn.feel.parser.feel11.FEELParser}}. {{errorChecker.hasErrors()}} is false, but it is not catched by the if statement in line 111. Because of this, {{errorChecker.getErrors()}} returns null instead of a {{List<FEELEvent>}}. > The method {{checkVariableName}} in {{org.kie.dmn.core.compiler.DMNCompilerHelper}}, assumes that a list will be returned and calls {{isEmpty()}}. This throws the {{NullPointerException}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2020