[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5973:
-----------------------------------
Issue Type: Feature Request (was: Bug)
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Feature Request
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6032) Class name conflict by class "D" in exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-6032?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-6032 at 2/16/21 4:03 AM:
--------------------------------------------------------------------
Thanks [~lucamolteni] , I took a look at the patch and I agree that it would be easier if we can remove FLOW first. I think it's okay to change "D" to "X" (or whatever) as a workaround in the meantime so this JIRA is not urgent.
Btw, the linked PR (https://github.com/kiegroup/drools/pull/3385) is not a fix of this issue so please ignore it (just mentioned this JIRA in a commit message)
was (Author: tkobayashi):
Thanks [~lucamolteni] , I took a look at the patch and I agree that it would be easier if we can remove FLOW first. I think it's okay to change "D" to "X" (or whatever) as a workaround in the meantime so this JIRA is not urgent.
> Class name conflict by class "D" in exec-model
> ----------------------------------------------
>
> Key: DROOLS-6032
> URL: https://issues.redhat.com/browse/DROOLS-6032
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.50.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Attachments: FQN_first_draft,_uses_static_fields.patch
>
>
> If you use a fact class named "D", you will hit errors during executable-model code generation.
> {code:java}
> @Test
> public void testClassNameConflict() {
> String str =
> "import " + D.class.getCanonicalName() + ";" +
> "rule R when\n" +
> " D(name == \"John\")\n" +
> "then\n" +
> "end";
> KieSession ksession = getKieSession( str );
> D fact = new D("John");
> ksession.insert( fact );
> assertEquals(1, ksession.fireAllRules());
> }
> public static class D {
> private String name;
> public D(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
> {code}
> {noformat}
> [ERROR] CompilerTest.testClassNameConflict:2573->BaseModelTest.getKieSession:111->BaseModelTest.getKieSession:115->BaseModelTest.getKieContainer:119->BaseModelTest.getKieContainer:126->BaseModelTest.createKieBuilder:137->BaseModelTest.createKieBuilder:164 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=5, column=1
> text=a type with the same simple name is already defined by the single-type-import of org.drools.modelcompiler.dsl.pattern.D], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java in error:
> package defaultpkg;
> import org.drools.modelcompiler.dsl.pattern.D;
> import org.drools.model.Index.ConstraintType;
> import org.drools.modelcompiler.CompilerTest.D;
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6032) Class name conflict by class "D" in exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-6032?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-6032:
-------------------------------------------
Thanks [~lucamolteni] , I took a look at the patch and I agree that it would be easier if we can remove FLOW first. I think it's okay to change "D" to "X" (or whatever) as a workaround in the meantime so this JIRA is not urgent.
> Class name conflict by class "D" in exec-model
> ----------------------------------------------
>
> Key: DROOLS-6032
> URL: https://issues.redhat.com/browse/DROOLS-6032
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.50.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Attachments: FQN_first_draft,_uses_static_fields.patch
>
>
> If you use a fact class named "D", you will hit errors during executable-model code generation.
> {code:java}
> @Test
> public void testClassNameConflict() {
> String str =
> "import " + D.class.getCanonicalName() + ";" +
> "rule R when\n" +
> " D(name == \"John\")\n" +
> "then\n" +
> "end";
> KieSession ksession = getKieSession( str );
> D fact = new D("John");
> ksession.insert( fact );
> assertEquals(1, ksession.fireAllRules());
> }
> public static class D {
> private String name;
> public D(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
> {code}
> {noformat}
> [ERROR] CompilerTest.testClassNameConflict:2573->BaseModelTest.getKieSession:111->BaseModelTest.getKieSession:115->BaseModelTest.getKieContainer:119->BaseModelTest.getKieContainer:126->BaseModelTest.createKieBuilder:137->BaseModelTest.createKieBuilder:164 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=5, column=1
> text=a type with the same simple name is already defined by the single-type-import of org.drools.modelcompiler.dsl.pattern.D], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java in error:
> package defaultpkg;
> import org.drools.modelcompiler.dsl.pattern.D;
> import org.drools.model.Index.ConstraintType;
> import org.drools.modelcompiler.CompilerTest.D;
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (WFLY-14403) Create test to verify expressions are resolved correctly
by Ivan Straka (Jira)
[ https://issues.redhat.com/browse/WFLY-14403?page=com.atlassian.jira.plugi... ]
Ivan Straka updated WFLY-14403:
-------------------------------
Summary: Create test to verify expressions are resolved correctly (was: Create test for to verify expressions are resolved correctly)
> Create test to verify expressions are resolved correctly
> --------------------------------------------------------
>
> Key: WFLY-14403
> URL: https://issues.redhat.com/browse/WFLY-14403
> Project: WildFly
> Issue Type: Enhancement
> Components: Test Suite
> Reporter: Ivan Straka
> Assignee: Ivan Straka
> Priority: Critical
>
> This is a followup on JBEAP-20356.
> In order to make sure there are no undetected problems of the kind described in JBEAP-20356, there should be a mechanism, which will allow for relatively simple testing of properties which have {{expression-allowed}} set to true.
> Currently, the only known reliable way of testing this, is to write a runtime test per property/small set of properties. Since there are about 2000 properties which are currently set to be resolvable, this is not realistic.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6032) Class name conflict by class "D" in exec-model
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-6032?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi edited comment on DROOLS-6032 at 2/16/21 3:40 AM:
--------------------------------------------------------------------
Possible approaches to fix:
* Use FQCN for all org.drools.modelcompiler.dsl.pattern.D / org.drools.modelcompiler.dsl.flow.D occurrences instead of using import. Note: Currently generated codes switches the PATTERN/FLOW "D" class by the import.
Or
* Use FQCN for all fact Classes instead of using import
was (Author: tkobayashi):
Possible approaches to fix:
* Use FQCN for all org.drools.modelcompiler.dsl.pattern.D / org.drools.modelcompiler.CompilerTest.D occurrences instead of using import. Note: Currently generated codes switches the PATTERN/FLOW "D" class by the import.
Or
* Use FQCN for all fact Classes instead of using import
> Class name conflict by class "D" in exec-model
> ----------------------------------------------
>
> Key: DROOLS-6032
> URL: https://issues.redhat.com/browse/DROOLS-6032
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.50.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Attachments: FQN_first_draft,_uses_static_fields.patch
>
>
> If you use a fact class named "D", you will hit errors during executable-model code generation.
> {code:java}
> @Test
> public void testClassNameConflict() {
> String str =
> "import " + D.class.getCanonicalName() + ";" +
> "rule R when\n" +
> " D(name == \"John\")\n" +
> "then\n" +
> "end";
> KieSession ksession = getKieSession( str );
> D fact = new D("John");
> ksession.insert( fact );
> assertEquals(1, ksession.fireAllRules());
> }
> public static class D {
> private String name;
> public D(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
> {code}
> {noformat}
> [ERROR] CompilerTest.testClassNameConflict:2573->BaseModelTest.getKieSession:111->BaseModelTest.getKieSession:115->BaseModelTest.getKieContainer:119->BaseModelTest.getKieContainer:126->BaseModelTest.createKieBuilder:137->BaseModelTest.createKieBuilder:164 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=5, column=1
> text=a type with the same simple name is already defined by the single-type-import of org.drools.modelcompiler.dsl.pattern.D], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java in error:
> package defaultpkg;
> import org.drools.modelcompiler.dsl.pattern.D;
> import org.drools.model.Index.ConstraintType;
> import org.drools.modelcompiler.CompilerTest.D;
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6032) Class name conflict by class "D" in exec-model
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-6032?page=com.atlassian.jira.plug... ]
Luca Molteni commented on DROOLS-6032:
--------------------------------------
[~tkobayashi] I've uploaded a patch for a first draft of using the FQCN.
I started working on it on Friday but I found a few problem with it:
- We're using static fields for constants and the methods generating Java Parser code, and I didn't want to change all of them to non-static to get access to `isPattern` field in the context.
- I didn't want also to add a boolean parameter to every static method, it seemed wrong to me (and didn't solve the static constant problem)
In the end I realised that it's probably better if we remove the Flow before and try to migrate to FQCN after, what do you think?
In the meanwhile I changed the `D` with `X` as a placeholder. We could use other workarounds (such as renaming the `.pattern.D` class but would break backwards compatibility.
Tell me if you take a look at the patch
I also link a related Jira issue
> Class name conflict by class "D" in exec-model
> ----------------------------------------------
>
> Key: DROOLS-6032
> URL: https://issues.redhat.com/browse/DROOLS-6032
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.50.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Attachments: FQN_first_draft,_uses_static_fields.patch
>
>
> If you use a fact class named "D", you will hit errors during executable-model code generation.
> {code:java}
> @Test
> public void testClassNameConflict() {
> String str =
> "import " + D.class.getCanonicalName() + ";" +
> "rule R when\n" +
> " D(name == \"John\")\n" +
> "then\n" +
> "end";
> KieSession ksession = getKieSession( str );
> D fact = new D("John");
> ksession.insert( fact );
> assertEquals(1, ksession.fireAllRules());
> }
> public static class D {
> private String name;
> public D(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
> {code}
> {noformat}
> [ERROR] CompilerTest.testClassNameConflict:2573->BaseModelTest.getKieSession:111->BaseModelTest.getKieSession:115->BaseModelTest.getKieContainer:119->BaseModelTest.getKieContainer:126->BaseModelTest.createKieBuilder:137->BaseModelTest.createKieBuilder:164 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=5, column=1
> text=a type with the same simple name is already defined by the single-type-import of org.drools.modelcompiler.dsl.pattern.D], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java in error:
> package defaultpkg;
> import org.drools.modelcompiler.dsl.pattern.D;
> import org.drools.model.Index.ConstraintType;
> import org.drools.modelcompiler.CompilerTest.D;
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6032) Class name conflict by class "D" in exec-model
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-6032?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-6032:
---------------------------------
Attachment: FQN_first_draft,_uses_static_fields.patch
> Class name conflict by class "D" in exec-model
> ----------------------------------------------
>
> Key: DROOLS-6032
> URL: https://issues.redhat.com/browse/DROOLS-6032
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.50.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
> Attachments: FQN_first_draft,_uses_static_fields.patch
>
>
> If you use a fact class named "D", you will hit errors during executable-model code generation.
> {code:java}
> @Test
> public void testClassNameConflict() {
> String str =
> "import " + D.class.getCanonicalName() + ";" +
> "rule R when\n" +
> " D(name == \"John\")\n" +
> "then\n" +
> "end";
> KieSession ksession = getKieSession( str );
> D fact = new D("John");
> ksession.insert( fact );
> assertEquals(1, ksession.fireAllRules());
> }
> public static class D {
> private String name;
> public D(String name) {
> this.name = name;
> }
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
> {code}
> {noformat}
> [ERROR] CompilerTest.testClassNameConflict:2573->BaseModelTest.getKieSession:111->BaseModelTest.getKieSession:115->BaseModelTest.getKieContainer:119->BaseModelTest.getKieContainer:126->BaseModelTest.createKieBuilder:137->BaseModelTest.createKieBuilder:164 [Message [id=1, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=5, column=1
> text=a type with the same simple name is already defined by the single-type-import of org.drools.modelcompiler.dsl.pattern.D], Message [id=2, level=ERROR, path=src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java, line=0, column=0
> text=Java source of src/main/java/defaultpkg/RulesF625E96E2F948CA04652DBAC4C6DBB79.java in error:
> package defaultpkg;
> import org.drools.modelcompiler.dsl.pattern.D;
> import org.drools.model.Index.ConstraintType;
> import org.drools.modelcompiler.CompilerTest.D;
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-6030) Evaluate "KieBase.addPackage" replacement effort from PMML
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-6030?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-6030:
-------------------------------------
[~gabriolo]
Thanks for quick reply. I'm giving a look into this. Correct me if I'm wrong but 1) doesn't seem related with this issue because there you're using the addPackage method of the KnowledgeBuilder, not the KieBase one and that one is perfectly fine. There you're adding the packages to be built to the builder and then a new KieBase will be created from there.
What [~lucamolteni] pointed out to be more problematic is the usage of the addPackage method directly on the KieBase that you have in 2). By doing so you're no longer adding packages to a builder and then obtaining the KieBase with the required packages from the builder, but you're adding packages (here I'm generally speaking about "packages" but of course they're a different thing at this stage) directly to an already existing KieBase.
I don't know how feasible it is in your context (and if I remember correctly we already discussed this) but ideally we should have in 2) something similar to what we have in 1), i.e. putting together the packages to be included in the KieBase at building time.
> Evaluate "KieBase.addPackage" replacement effort from PMML
> ----------------------------------------------------------
>
> Key: DROOLS-6030
> URL: https://issues.redhat.com/browse/DROOLS-6030
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Major
>
> Currently, the method KieBase.addPackage(s) is used inside PMML in two classes
> 1) PMMLLoaderService.loadPMMLRuleMappers
> 2) PMMLRuntimeFactoryInternal.getPMMLRuntime(String, String, KieBase)
> 3) PMMLRuntimeFactoryInternal.createKieBase(KnowledgeBuilderImpl)
> In all those cases the needs is to create a "clean" kiebase that contains only the model-specific packages, to avoid name/session clashing.
> Scope of the current ticket is to evaluate an alternative, since the method itself is going to be deprecated.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month
[Red Hat JIRA] (DROOLS-5973) Java enum values don't match DNM enumerations when input passed as POJO
by Andrew K (Jira)
[ https://issues.redhat.com/browse/DROOLS-5973?page=com.atlassian.jira.plug... ]
Andrew K commented on DROOLS-5973:
----------------------------------
Hi Matteo,
Thanks for the comprehensive explanation.
Perhaps it's not a bug, but instead a feature request.
There is currently no way to specify an enumeration in DMN in such a way as that a Java Enum can be passed in as-is and matched to the DMN enumeration values. If, for example, my input parameter is something like the MyObject type below, I have to modify the entire object structure to handle the MyEnum type - and that is not great.
{code:java}
class MyObject {
NestedObject nestedObject;
}
class NestedObject {
MyEnum myEnum;
}
enum MyEnum {
Daily,
Weekly,
Monthly
}{code}
For me, it would make a lot of sense for a Java Enum to behave considered as equivalent to the string returned by .name().
If you have a method to coerce Enum values nested inside objects in a more efficient way than using ObjectMapper to convert the entire object structure into a Map, this would satisfy the use case - I think the ObjectMapper workaround is a little cumbersome.
> Java enum values don't match DNM enumerations when input passed as POJO
> -----------------------------------------------------------------------
>
> Key: DROOLS-5973
> URL: https://issues.redhat.com/browse/DROOLS-5973
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.48.0.Final
> Reporter: Andrew K
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, screenshot-4.png
>
>
> When passing an input object into the DMN engine as a POJO, enumerations represented in the POJO as Java enums do not correctly match DMN string enumerations.
> This can be worked around by converting the input to a Map using Jackson:
> {code:java}
> new ObjectMapper().convertValue(pojo, Map.class){code}
> but this should not be necessary.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 1 month