July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4187) kie-dmn-validation: Incorrect import detection

by Emily Murphy (Jira)

[ https://issues.jboss.org/browse/DROOLS-4187?page=com.atlassian.jira.plugi... ] Emily Murphy commented on DROOLS-4187: -------------------------------------- [~manstis] [~tirelli] I have added this issue to the 7.4 release notes draft, [Known Issues|http://file.ork.redhat.com/~emmurphy/rhpam-7.4-rn/#rn-known-issues...] section. The PR is [here|https://github.com/emmurphy1/kie-docs/pull/175]. Search for DROOLS-4187 to find it in the draft. Please create an RHPAM or RHDM jira that I can include in the release notes and consider using the title I have given this issue in the release notes in that new jira. Please provide the following: Steps to Reproduce:: Actual Result: Expected Result: Workaround: Please review and either comment or approve by Monday, July 8th. [~rrajesh1] FYI. > kie-dmn-validation: Incorrect import detection > ---------------------------------------------- > > Key: DROOLS-4187 > URL: https://issues.jboss.org/browse/DROOLS-4187 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.23.0.Final > Reporter: Michael Anstis > Assignee: Edson Tirelli > Priority: Critical > Labels: rhpam74releasenote > Attachments: DROOLS-4187 > > > If I have a DMN file with {{Definitions}} attribute {{namespace}} and {{name}} both populated imported into another DMN file that does not use the {{drools:modelName}} extension in the {{Import}} node; validation of the imported model fails. > See https://github.com/kiegroup/drools/commit/d057e0113c8e519a07554569f512045... -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4243) Test Scenario: rule scenarios with maps of simple types are failing

by Emily Murphy (Jira)

[ https://issues.jboss.org/browse/DROOLS-4243?page=com.atlassian.jira.plugi... ] Emily Murphy commented on DROOLS-4243: -------------------------------------- [~dzonca] [~kkufova] I have added this issue to the 7.4 release notes draft, [Known Issues|http://file.ork.redhat.com/~emmurphy/rhpam-7.4-rn/#rn-known-issues...] section. The PR is [here|https://github.com/emmurphy1/kie-docs/pull/175]. Search for DROOLS-4243 to find it in the draft. Please create an RHPAM or RHDM jira that I can include in the release notes and consider using the title I have given this issue in the release notes in that new jira. Please provide a better description for the issue than I have currently. Please review and either comment or approve by Monday, July 8th. [~rrajesh1] FYI. > Test Scenario: rule scenarios with maps of simple types are failing > ------------------------------------------------------------------- > > Key: DROOLS-4243 > URL: https://issues.jboss.org/browse/DROOLS-4243 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Critical > Labels: ScenarioSimulation, rhpam74releasenote > > Create a map of simple type as value (i.e. Map<String, String>) and try to use it -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4259) Scenario can not access parent data object fields

by Emily Murphy (Jira)

[ https://issues.jboss.org/browse/DROOLS-4259?page=com.atlassian.jira.plugi... ] Emily Murphy commented on DROOLS-4259: -------------------------------------- [~manstis] I have added this issue to the 7.4 release notes draft, [Known Issues|http://file.ork.redhat.com/~emmurphy/rhpam-7.4-rn/#rn-known-issues...] section. The PR is [here|https://github.com/emmurphy1/kie-docs/pull/175]. Search for DROOLS-4259 to find it in the draft. Please create an RHPAM or RHDM jira that I can include in the release notes and consider using the title I have given this issue in the release notes in that new jira. Please review and either comment or approve by Monday, July 8th. [~rrajesh1] FYI. > Scenario can not access parent data object fields > ------------------------------------------------- > > Key: DROOLS-4259 > URL: https://issues.jboss.org/browse/DROOLS-4259 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.24.0.Final > Reporter: Jozef Marko > Assignee: Daniele Zonca > Priority: Critical > Labels: ScenarioSimulation, rhpam74releasenote > Attachments: Screenshot from 2019-06-26 08-56-23.png, inheritance.zip > > > Scenario Designer can not access parent data object fields, even if the field has public getter and setter. If you check the attached project there are two fields - *price* and *size* while *size* is declared in parent class. If you try to run the scenario, error about not possible initialization of the data object appears. > If you move the *size* field from *Picture* into *Advertisement* class and rerun the scenario, everything works fine. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4275) Drools-wb webapp does not start

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4275?page=com.atlassian.jira.plugi... ] Gabriele Cardosi commented on DROOLS-4275: ------------------------------------------ [~danielezonca] WDYT ^ ? > Drools-wb webapp does not start > ------------------------------- > > Key: DROOLS-4275 > URL: https://issues.jboss.org/browse/DROOLS-4275 > Project: Drools > Issue Type: Bug > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Blocker > Labels: rhpam74releasenote > > Drools-wb webapp jboss does not start due to ambiguous dependencies at WELD -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4275) Drools-wb webapp does not start

by Emily Murphy (Jira)

[ https://issues.jboss.org/browse/DROOLS-4275?page=com.atlassian.jira.plugi... ] Emily Murphy commented on DROOLS-4275: -------------------------------------- [~gabriolo] will this issue be fixed in BA 7.4.0 GA? > Drools-wb webapp does not start > ------------------------------- > > Key: DROOLS-4275 > URL: https://issues.jboss.org/browse/DROOLS-4275 > Project: Drools > Issue Type: Bug > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Blocker > Labels: rhpam74releasenote > > Drools-wb webapp jboss does not start due to ambiguous dependencies at WELD -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4291) ModelWriter: refactor to smaller classes

by Edoardo Vacchi (Jira)

Edoardo Vacchi created DROOLS-4291: -------------------------------------- Summary: ModelWriter: refactor to smaller classes Key: DROOLS-4291 URL: https://issues.jboss.org/browse/DROOLS-4291 Project: Drools Issue Type: Enhancement Reporter: Edoardo Vacchi Assignee: Edoardo Vacchi ModelWriter performs most of the logic translating PackageModel into source files; then it writes the result to a virtual FS. This makes it harder to reuse common source-to-file logic. In this PR we refactor each part of the PackageModel-to-individual-source-files into separate classes, taking each one single component. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4161) Scenario Test: UX for DMN Decision service

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-4161?page=com.atlassian.jira.plugi... ] Daniele Zonca commented on DROOLS-4161: --------------------------------------- [~kkufova] Fine for me, let's finalize the UX about Decision Serving assuming that we have in place DROOLS-3570 and then we will implement for the other feature > Scenario Test: UX for DMN Decision service > ------------------------------------------ > > Key: DROOLS-4161 > URL: https://issues.jboss.org/browse/DROOLS-4161 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Tao Zhu > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > > As user I want to test my decision service from a DMN model. > User needs to specify DMN model and decision service name to be tested. > Note: a decision service contains only a subset of decisions so the template (header) need to be updated/recreated or the information needs to be available during template creation -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4559) Incorrectly formatted result produced by LocalPatchOperationTarget.info(stream)

by Oleksiy Lubyanskyy (Jira)

[ https://issues.jboss.org/browse/WFCORE-4559?page=com.atlassian.jira.plugi... ] Oleksiy Lubyanskyy updated WFCORE-4559: --------------------------------------- Description: Addon patches are added to the wrong instance of ModelNode which breaks the CLI `patch info --verbose`. Here is how it should be fixed {code:java} diff --git a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java index e739c73847..4901ccc25d 100644 --- a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java +++ b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java @@ -183,9 +183,10 @@ public abstract class PatchOperationTarget { } } if(vInfo.hasAddOns()) { - final ModelNode layerNode = result.get(Constants.ADD_ON); + final ModelNode layersNode = result.get(Constants.ADD_ON); for(String name : vInfo.getAddOnNames()) { final TargetInfo layerInfo = vInfo.getAddOnInfo(name); + final ModelNode layerNode = layersNode.get(name); layerNode.get(Constants.CUMULATIVE).set(layerInfo.getCumulativePatchID()); final ModelNode patchesNode = layerNode.get(Constants.PATCHES).setEmptyList(); if(!layerInfo.getPatchIDs().isEmpty()) { {code} was: Addon patches are added to the wrong instance of ModelNode which breaks the CLI `patch info --verbose`. Here is how it should be fixed {code:java} diff --git a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java index e739c73847..4901ccc25d 100644 --- a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java +++ b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java @@ -183,9 +183,10 @@ public abstract class PatchOperationTarget { } } if(vInfo.hasAddOns()) { - final ModelNode layerNode = result.get(Constants.ADD_ON); + final ModelNode layersNode = result.get(Constants.ADD_ON); for(String name : vInfo.getAddOnNames()) { final TargetInfo layerInfo = vInfo.getAddOnInfo(name); + final ModelNode layerNode = layersNode.get(name); layerNode.get(name, Constants.CUMULATIVE).set(layerInfo.getCumulativePatchID()); final ModelNode patchesNode = layerNode.get(Constants.PATCHES).setEmptyList(); if(!layerInfo.getPatchIDs().isEmpty()) { {code} > Incorrectly formatted result produced by LocalPatchOperationTarget.info(stream) > ------------------------------------------------------------------------------- > > Key: WFCORE-4559 > URL: https://issues.jboss.org/browse/WFCORE-4559 > Project: WildFly Core > Issue Type: Bug > Components: Patching > Affects Versions: 10.0.0.Beta1 > Reporter: Oleksiy Lubyanskyy > Assignee: Oleksiy Lubyanskyy > Priority: Major > > Addon patches are added to the wrong instance of ModelNode which breaks the CLI `patch info --verbose`. Here is how it should be fixed > {code:java} > diff --git a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java > index e739c73847..4901ccc25d 100644 > --- a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java > +++ b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java > @@ -183,9 +183,10 @@ public abstract class PatchOperationTarget { > } > } > if(vInfo.hasAddOns()) { > - final ModelNode layerNode = result.get(Constants.ADD_ON); > + final ModelNode layersNode = result.get(Constants.ADD_ON); > for(String name : vInfo.getAddOnNames()) { > final TargetInfo layerInfo = vInfo.getAddOnInfo(name); > + final ModelNode layerNode = layersNode.get(name); > layerNode.get(Constants.CUMULATIVE).set(layerInfo.getCumulativePatchID()); > final ModelNode patchesNode = layerNode.get(Constants.PATCHES).setEmptyList(); > if(!layerInfo.getPatchIDs().isEmpty()) { > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4559) Incorrectly formatted result produced by LocalPatchOperationTarget.info(stream)

by Oleksiy Lubyanskyy (Jira)

Oleksiy Lubyanskyy created WFCORE-4559: ------------------------------------------ Summary: Incorrectly formatted result produced by LocalPatchOperationTarget.info(stream) Key: WFCORE-4559 URL: https://issues.jboss.org/browse/WFCORE-4559 Project: WildFly Core Issue Type: Bug Components: Patching Affects Versions: 10.0.0.Beta1 Reporter: Oleksiy Lubyanskyy Assignee: Oleksiy Lubyanskyy Addon patches are added to the wrong instance of ModelNode which breaks the CLI `patch info --verbose`. Here is how it should be fixed {code:java} diff --git a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java index e739c73847..4901ccc25d 100644 --- a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java +++ b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java @@ -183,9 +183,10 @@ public abstract class PatchOperationTarget { } } if(vInfo.hasAddOns()) { - final ModelNode layerNode = result.get(Constants.ADD_ON); + final ModelNode layersNode = result.get(Constants.ADD_ON); for(String name : vInfo.getAddOnNames()) { final TargetInfo layerInfo = vInfo.getAddOnInfo(name); + final ModelNode layerNode = layersNode.get(name); layerNode.get(name, Constants.CUMULATIVE).set(layerInfo.getCumulativePatchID()); final ModelNode patchesNode = layerNode.get(Constants.PATCHES).setEmptyList(); if(!layerInfo.getPatchIDs().isEmpty()) { {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 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.jboss.org/browse/DROOLS-4288?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-4288. --------------------------------- Resolution: Explained The change has been introduced by this commit https://github.com/kiegroup/drools/commit/aa986a57724e2f16cabea9c084b8e16... and it is actually a necessary fix. We cannot know what the external function (static method) does internally, so we cannot apply any property reactivity based flitering on that constraint. In this case the constraint has to be re-evaluated (and this is correct) thus causing the loop. > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4288 > URL: https://issues.jboss.org/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 > > 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.12.1#712002)

6 years, 10 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 July 2019