[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, 6 months
[JBoss JIRA] (DROOLS-4288) Infinite recursion in drools after version change from v7.20 to v7.21
by Crosson David (Jira)
[ https://issues.redhat.com/browse/DROOLS-4288?page=com.atlassian.jira.plug... ]
Crosson David commented on DROOLS-4288:
---------------------------------------
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, 6 months
[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, 6 months
[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, 6 months
[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, 6 months