[JBoss JIRA] (DROOLS-5102) DMN npe when xml defines empty default expression for DT
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5102?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5102:
----------------------------------------
Ciao [~eromano-1] , thank you very much for reporting!
Actually, there were several problems in your original DMN file, which from my perspective made the file non-spec-compliant:
* line 28: "The OutputClause of a single output decision table SHALL NOT specify a typeRef."
* line 28: "The OutputClause of a single output decision table SHALL NOT specify a name."
* line 63: my understanding from the spec this variable shall be given the same name of the Decision (DRGElement) it belongs to; hence this variable should have been named {{name="Decision_decisionboolean"}}
That said, the blocking issue at play here was that the DMN model file seems trying to define a default output entry (to be used when Unique DT does not match any rule, for instance) but this default output entry was "none".
See Line30.
Based on this decision table design, we could expect either {{true}} or {{false}} could be reasonable default output entry, when any other rule would not have matched.
Please notice, if the desire was to have the default to be null, Line 30 should have specified {{<text>null</text>}} instead.
Line30, originally in this file, is a none expression, which is a bit strange.
On other hand, and as you reported, it was not good that the Drools DMN engine was throwing the NPE during evaluation/execution, and I just raised a PR to fix this specific problem.
The other problems of the file are a modeler/editor issue, which from my perspective is creating a file failing to be fully compliant DMN-spec-compliant model, as explained above; you may also want to consider exporting DMN to the newest version available if possible, which is DMNv1.2 ;)
Hope this helps, thank you again for reporting!
> DMN npe when xml defines empty default expression for DT
> --------------------------------------------------------
>
> Key: DROOLS-5102
> URL: https://issues.redhat.com/browse/DROOLS-5102
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.33.0.Final
> Reporter: Eugenio Romano
> Assignee: Matteo Mortari
> Priority: Critical
> Attachments: different-all.dmn
>
>
> If you execute the DMN table in attach in the last version you will have a NullPointerException in case your input value is not matching any output.
> We are moving from version 23 to 33 and one of our tests are catching this issue
> The ProcessedExpression Class seems can be responsible of causing this NullPointerException.
> {code:java}
> this.ast = (BaseNode)tree.accept(new ASTBuilderVisitor(ctx.getInputVariableTypes(), ctx.getFEELFeelTypeRegistry()))
> {code}
> If you try with
> "inputString", "hi"
> "inputInteger", 12
> "inputBoolean", false
> "inputDate", "2019-09-26T00:00:00.000+0000"
> you can replicate the error
> I guess the expected behavior should be a null output as before
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5102) DMN npe when xml defines empty default expression for DT
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5102?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5102:
-----------------------------------
Summary: DMN npe when xml defines empty default expression for DT (was: Execute a Table with multiple input can cause NullPointerException)
> DMN npe when xml defines empty default expression for DT
> --------------------------------------------------------
>
> Key: DROOLS-5102
> URL: https://issues.redhat.com/browse/DROOLS-5102
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.33.0.Final
> Reporter: Eugenio Romano
> Assignee: Matteo Mortari
> Priority: Critical
> Attachments: different-all.dmn
>
>
> If you execute the DMN table in attach in the last version you will have a NullPointerException in case your input value is not matching any output.
> We are moving from version 23 to 33 and one of our tests are catching this issue
> The ProcessedExpression Class seems can be responsible of causing this NullPointerException.
> {code:java}
> this.ast = (BaseNode)tree.accept(new ASTBuilderVisitor(ctx.getInputVariableTypes(), ctx.getFEELFeelTypeRegistry()))
> {code}
> If you try with
> "inputString", "hi"
> "inputInteger", 12
> "inputBoolean", false
> "inputDate", "2019-09-26T00:00:00.000+0000"
> you can replicate the error
> I guess the expected behavior should be a null output as before
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (DROOLS-5102) Execute a Table with multiple input can cause NullPointerException
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5102?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5102:
-----------------------------------
Sprint: 2020 Week 07-09 (from Feb 10)
> Execute a Table with multiple input can cause NullPointerException
> ------------------------------------------------------------------
>
> Key: DROOLS-5102
> URL: https://issues.redhat.com/browse/DROOLS-5102
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.33.0.Final
> Reporter: Eugenio Romano
> Assignee: Matteo Mortari
> Priority: Critical
> Attachments: different-all.dmn
>
>
> If you execute the DMN table in attach in the last version you will have a NullPointerException in case your input value is not matching any output.
> We are moving from version 23 to 33 and one of our tests are catching this issue
> The ProcessedExpression Class seems can be responsible of causing this NullPointerException.
> {code:java}
> this.ast = (BaseNode)tree.accept(new ASTBuilderVisitor(ctx.getInputVariableTypes(), ctx.getFEELFeelTypeRegistry()))
> {code}
> If you try with
> "inputString", "hi"
> "inputInteger", 12
> "inputBoolean", false
> "inputDate", "2019-09-26T00:00:00.000+0000"
> you can replicate the error
> I guess the expected behavior should be a null output as before
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13150) Create a Galleon layer for distributable web
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13150?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13150:
------------------------------------
Summary: Create a Galleon layer for distributable web (was: Create a Galleon layer for distriibutable web)
> Create a Galleon layer for distributable web
> --------------------------------------------
>
> Key: WFLY-13150
> URL: https://issues.redhat.com/browse/WFLY-13150
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Web (Undertow)
> Reporter: Brian Stansberry
> Assignee: Paul Ferraro
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
> We have a web-clustering layer that provides the distributable-web subsystem and the related infinispan web session caching resources, configured for multi-server distributed sessions.
> We need a variant of this with infinispan configured for local caching.
> The WFLY-13099 standalone-microprofile.xml config should have this kind of setup; otherwise session sharing does not work . (A failure in org.jboss.as.test.clustering.cluster.web.shared.SharedSessionTestCase if the server uses a config without it shows this.) For WFLY-13099 I can work around this by adding the needed config stuff without a layer, but as everything else needed for those configs are from layers, it's better to use a layer in WF 20.
> Besides it's a good layer to have anyway. :)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (SWSQE-1076) Automate Codes: https://github.com/kiali/kiali/pull/2275/
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1076?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1076:
----------------------------------
Description:
Also automate:
"No matching workload found for authorization policy selector in this namespace"
"This subset is already referenced in another route destination"
"Destination field is mandatory"
"Unable to verify the validity, cross-namespace validation is not supported for this field"
was:
Also automate:
"No matching workload found for authorization policy selector in this namespace"
"This subset is already referenced in another route destination"
"Destination field is mandatory"
> Automate Codes: https://github.com/kiali/kiali/pull/2275/
> ---------------------------------------------------------
>
> Key: SWSQE-1076
> URL: https://issues.redhat.com/browse/SWSQE-1076
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Hayk Hovsepyan
> Priority: Major
> Labels: automation
>
> Also automate:
> "No matching workload found for authorization policy selector in this namespace"
> "This subset is already referenced in another route destination"
> "Destination field is mandatory"
> "Unable to verify the validity, cross-namespace validation is not supported for this field"
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13128) Add a Galleon layer for batch-jberet
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13128?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFLY-13128:
------------------------------------
Fix Version/s: 20.0.0.Beta1
> Add a Galleon layer for batch-jberet
> ------------------------------------
>
> Key: WFLY-13128
> URL: https://issues.redhat.com/browse/WFLY-13128
> Project: WildFly
> Issue Type: Feature Request
> Components: Batch
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
> I saw a community request for a Galleon layer for batch-jberet so let's make it first in the set we add to complete coverage of the various subsystems.
> Besides the usual layer smoke tests, we can provision a cloud-server+batch-jberet server in testsuite/integration/basic and run most of the batch tests there against it. There are 4 that won't run because they use EJB, Agroal or the org.jboss.remoting3 module, none of which would be provisioned.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months