[JBoss JIRA] (DROOLS-5649) [DMN XML] Signavio Profile - ZipFunction: parameter do not match
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5649?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5649:
----------------------------------------
With reference to the Signavio documentation:
!Screenshot 2020-09-17 at 16.18.25.png|thumbnail!
the UI will present the user the _varargs variant_, but Signavio DMN XML persists the _list-of-lists variant_, so this code change address this behaviour.
In other words, the user on the Signavio UI will operate using
{code:java}
zip(["name", "age"], ["Alice", "Bob"], [ 47, 48] )
{code}
but the DMN XML model is always persisted as:
{code:java}
zip(["name", "age"], [["Alice", "Bob"], [ 47, 48]] )
{code}
Addressed with: https://github.com/kiegroup/drools/commit/15b89913244445cef846965c88e41f6...
> [DMN XML] Signavio Profile - ZipFunction: parameter do not match
> ----------------------------------------------------------------
>
> Key: DROOLS-5649
> URL: https://issues.redhat.com/browse/DROOLS-5649
> Project: Drools
> Issue Type: Bug
> Reporter: Tommy Neubert
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: Screenshot 2020-09-17 at 16.18.25.png
>
>
> h2. 1. Synopsis
> In order to allow the execution of dmn.xml files exported by the Signavio Process Manager, the Signavio Profile ([https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-signavio|h...]) contains all custom made functions.
> The zip-function that is contained in this profile however expects its parameters in a different format then the Signavio Process Manager exports. This causes the parsing/execution of such dmn.xml files to fail. Customers have to manually adjust the xml file in order to get there executions running. This is both inconvenient and error prone and should be fixed.
> h2. 2. Technical Details
> As described above the parameters of the zip-function do not match
> Signavio Process Manager Export:
> {code:java}
> zip(["name", "age"], [names, ages]){code}
> Signavio Profiles expected parameters:
> {code:java}
> zip(["name", "age"], names, ages)
> {code}
> Codepointer:
> [https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-signavio/s...]
> h2. 3. Acceptance Criteria
> # zip-function exported by the Signavio Process Manager should be executable without manual adjustments
> # [backwards compatible]existing dmn.xml files (with manual adjustments) should still be exectuable
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Abhi Vuyyuru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Abhi Vuyyuru commented on DROOLS-5650:
--------------------------------------
I was trying to replicate with a simpler example, and used the example from github. The addition I did was to ad AuditVO with nested class. Policy now extends AuditVO. I put this in our Weblogic application and ran it, and got the same error message (ASM7 required).
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
> Attachments: AuditVO.java, Driver.java, ExamplePolicyPricing.xls, Policy.java
>
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5649) [DMN XML] Signavio Profile - ZipFunction: parameter do not match
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5649?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5649:
-----------------------------------
Attachment: Screenshot 2020-09-17 at 16.18.25.png
> [DMN XML] Signavio Profile - ZipFunction: parameter do not match
> ----------------------------------------------------------------
>
> Key: DROOLS-5649
> URL: https://issues.redhat.com/browse/DROOLS-5649
> Project: Drools
> Issue Type: Bug
> Reporter: Tommy Neubert
> Assignee: Matteo Mortari
> Priority: Minor
> Attachments: Screenshot 2020-09-17 at 16.18.25.png
>
>
> h2. 1. Synopsis
> In order to allow the execution of dmn.xml files exported by the Signavio Process Manager, the Signavio Profile ([https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-signavio|h...]) contains all custom made functions.
> The zip-function that is contained in this profile however expects its parameters in a different format then the Signavio Process Manager exports. This causes the parsing/execution of such dmn.xml files to fail. Customers have to manually adjust the xml file in order to get there executions running. This is both inconvenient and error prone and should be fixed.
> h2. 2. Technical Details
> As described above the parameters of the zip-function do not match
> Signavio Process Manager Export:
> {code:java}
> zip(["name", "age"], [names, ages]){code}
> Signavio Profiles expected parameters:
> {code:java}
> zip(["name", "age"], names, ages)
> {code}
> Codepointer:
> [https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-signavio/s...]
> h2. 3. Acceptance Criteria
> # zip-function exported by the Signavio Process Manager should be executable without manual adjustments
> # [backwards compatible]existing dmn.xml files (with manual adjustments) should still be exectuable
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Abhi Vuyyuru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Abhi Vuyyuru updated DROOLS-5650:
---------------------------------
Attachment: Driver.java
Policy.java
AuditVO.java
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
> Attachments: AuditVO.java, Driver.java, ExamplePolicyPricing.xls, Policy.java
>
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Abhi Vuyyuru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Abhi Vuyyuru updated DROOLS-5650:
---------------------------------
Attachment: ExamplePolicyPricing.xls
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
> Attachments: ExamplePolicyPricing.xls
>
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5655) ObjectDataCompiler converter does not compile all template rules
by Oualid AMCHAYD (Jira)
Oualid AMCHAYD created DROOLS-5655:
--------------------------------------
Summary: ObjectDataCompiler converter does not compile all template rules
Key: DROOLS-5655
URL: https://issues.redhat.com/browse/DROOLS-5655
Project: Drools
Issue Type: Bug
Reporter: Oualid AMCHAYD
Assignee: Mario Fusco
Attachments: image-2020-09-18-11-31-28-879.png
When trying to compile a rule template with a datasource, the compilers does not compiles the rows with empty fields.
Here is the code I am using:
{code:java}
ObjectDataCompiler converter = new ObjectDataCompiler();
Collection<MyRule> rulesRep = rulerepo.findAll();
InputStream personInputStream = null;
try {
personInputStream = ResourceFactory.newClassPathResource("rules.drt").getInputStream(); // convert sample.drt in resource to input stream
} catch (IOException e) {
e.printStackTrace();
}
KieFileSystem kieFileSystem = kieServices.newKieFileSystem();
String personDrl = converter.compile(rulesRep, personInputStream);
kieFileSystem.write("src/main/resources/person_rule.drl", kieServices.getResources().newReaderResource(new StringReader(personDrl)));
{code}
This is my datasource, which have two empty fields in two rows.
!image-2020-09-18-11-31-28-879.png!
And this is the result i got for the two rows with an empty fields :
{code:java}
rule "ageRule_1"
when
then
$person.setStatus("Infant");
end
rule "ageRule_8"
when
then
$person.setStatus("Old Aged");
end
{code}
As you see the LHS are is generated in two rules.
Am i missing something or this is a normal behaviour when having empty fields.
Thanks in advance.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months
[JBoss JIRA] (DROOLS-5650) UnsupportedOperationException when using enum in Java 11, works fine in Java 8
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5650?page=com.atlassian.jira.plug... ]
Mario Fusco commented on DROOLS-5650:
-------------------------------------
[~abhi_tx] I ran our complete test suite (again) against Java 11 and all tests succeeded. I'm pretty sure we have lot's of test cases using enums and/or inner classes, so I still don't see how to reproduce this issue. Can you please give me some hints?
> UnsupportedOperationException when using enum in Java 11, works fine in Java 8
> ------------------------------------------------------------------------------
>
> Key: DROOLS-5650
> URL: https://issues.redhat.com/browse/DROOLS-5650
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.43.1.Final
> Reporter: Abhi Vuyyuru
> Assignee: Mario Fusco
> Priority: Major
>
> I am porting an existing application Java 7 to Java 11 (Drools 7.42.0). The application works as expected if I compile as Java 1.8 and deploy on Java 11 container (Weblogic 14). But if I compile the same code in Java 11, I get the following error. The only change between 1.8 and 11 is the java compiler level in Maven pom. I have ASM7 as a dependency in Maven.
> {{}}
>
> {{{{Caused by: java.lang.UnsupportedOperationException: This feature requires ASM7
> at org.mvel2.asm.ClassVisitor.visitNestMember(ClassVisitor.java:236)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:651)
> at org.mvel2.asm.ClassReader.accept(ClassReader.java:391)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:107)
> at org.drools.core.util.asm.ClassFieldInspector.processClassWithByteCode(ClassFieldInspector.java:114)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:86)
> at org.drools.core.util.asm.ClassFieldInspector.<init>(ClassFieldInspector.java:74)
> at org.drools.core.base.ClassFieldAccessorFactory.getClassFieldInspector(ClassFieldAccessorFactory.java:157)
> at org.drools.core.base.ClassFieldAccessorFactory.getFieldType(ClassFieldAccessorFactory.java:141)
> at org.drools.core.base.ClassFieldAccessorStore.getFieldType(ClassFieldAccessorStore.java:295)
> at org.drools.compiler.rule.builder.PatternBuilder.getValueType(PatternBuilder.java:1079)
> at org.drools.compiler.rule.builder.PatternBuilder.normalizeExpression(PatternBuilder.java:1047)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:965)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:942)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:767)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:620)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:187)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:154)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:136)
> at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
> at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:107)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.internalAddRule(KnowledgeBuilderImpl.java:1183)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1178)
> at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$null$3(KnowledgeBuilderImpl.java:1134)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
> at java.base/java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:746)}}}}
>
> I noticed while debugging that this was caused by an "enum" in our code. Drools works fine if we remove the enum and use constants. The error seems to suggest that this could happen to any nested classes. Is there a better way to handle this other than changing our code to remove nested classes and enums?
> I see that in the class {{org.drools.core.util.asm.ClassFieldInspector}}, the API is set to ASM5, but MVEL is expecting ASM7. But not sure why it would work in Java 8 and not in Java 11. Any suggestions?
>
> {{ClassFieldVisitor(final Class< ? > cls,
> final boolean includeFinalMethods,
> final ClassFieldInspector inspector) \{
> super(Opcodes.ASM5);
> this.clazz = cls;
> this.includeFinalMethods = includeFinalMethods;
> this.inspector = inspector;
> }}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 8 months