[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Description:
We are experiencing cluster is not formed in one of our tests [1] with XP image [2]. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
was:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image [2]. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Description:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} this log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
was:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} this log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-not-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} this log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Steps to Reproduce: (was: {code}mvn test -Pxp,operator -Dxtf.test_properties.path=test.properties.os-ocp42 -Dtest=OperatorKubePingTest{code})
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} this log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Description:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
was:
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} this log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-318?page=com.atlassian.jira.plugin... ]
Martin Choma updated WFWIP-318:
-------------------------------
Attachment: KUBE_PING-xp-cluster-formed.log
KUBE_PING-73-cluster-formed.log
KUBE_PING-xp-cluster-not-formed.log
> [XP] Cluster not formed. Same test works with 7.3.0.GA image
> ------------------------------------------------------------
>
> Key: WFWIP-318
> URL: https://issues.redhat.com/browse/WFWIP-318
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
>
>
> We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
> Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
> Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
> Comparing logs I am missing {{clustering enabled}} this log message in xp case.
> {code}
> [0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
> {code}
> Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
> - JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
> - port 8080 on container: can't be configured on Operator
> - port(8888, "ping"): can't be configured on Operator
> - readiness probe explicitely set: This is set on Operator as well implicitely.
> Not sure what aspect of Operator launching can prevent cluster from forming properly.
> [1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
> [2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
> [3] KUBE_PING-xp-cluster-not-formed.log
> [4] KUBE_PING-73-cluster-formed.log
> [5] KUBE_PING-xp-cluster-not-formed.log
> [6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (WFWIP-318) [XP] Cluster not formed. Same test works with 7.3.0.GA image
by Martin Choma (Jira)
Martin Choma created WFWIP-318:
----------------------------------
Summary: [XP] Cluster not formed. Same test works with 7.3.0.GA image
Key: WFWIP-318
URL: https://issues.redhat.com/browse/WFWIP-318
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Martin Choma
Assignee: Jeff Mesnil
Attachments: KUBE_PING-73-cluster-formed.log, KUBE_PING-xp-cluster-formed.log, KUBE_PING-xp-cluster-not-formed.log
We are experiencing cluster is not formed in one of our tests [1] with XP image. You can see log of such pod in attachemnt [3]
Same test with same configuration works Ok with 7.3.0.GA image. See log [4]
Test is about Operator (same version in both cases) deploying multiple instances of application running in multiple pods, such that EAP are creating cluster.
Comparing logs I am missing {{clustering enabled}} this log message in xp case.
{code}
[0m[0m11:55:44,554 INFO [org.jgroups.protocols.kubernetes.KUBE_PING] (ServerService Thread Pool -- 62) namespace mchoma-tmp set; clustering enabled
{code}
Strange is we see with XP image cluster is created in non Operator scenario [5]. There are few differences in configuration:
- JGROUPS_CLUSTER_PASSWORD: didn't helped in Operator scenario
- port 8080 on container: can't be configured on Operator
- port(8888, "ping"): can't be configured on Operator
- readiness probe explicitely set: This is set on Operator as well implicitely.
Not sure what aspect of Operator launching can prevent cluster from forming properly.
[1] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
[2] https://issues.redhat.com/browse/EAP7-1484?focusedCommentId=14041773&page...
[3] KUBE_PING-xp-cluster-not-formed.log
[4] KUBE_PING-73-cluster-formed.log
[5] KUBE_PING-xp-cluster-not-formed.log
[6] https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-eap/openshift-eap-tests/...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5280:
-----------------------------------
Tester: Daniel Rosa
Story Points: 3
> List Filter expression returning single item and nested within arithmetic expression fails to evaluate
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5280
> URL: https://issues.redhat.com/browse/DROOLS-5280
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.34.0.Final, 7.36.0.Final
> Reporter: Tracy Hires
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug... ]
Matteo Mortari resolved DROOLS-5280.
------------------------------------
Resolution: Rejected
> List Filter expression returning single item and nested within arithmetic expression fails to evaluate
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5280
> URL: https://issues.redhat.com/browse/DROOLS-5280
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.34.0.Final, 7.36.0.Final
> Reporter: Tracy Hires
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug... ]
Matteo Mortari commented on DROOLS-5280:
----------------------------------------
[~tracyhires] thank you for reporting but there is no bug, and I believe while creating this model a specific semantic feature of DMN FEEL expressions has been overlooked; in the below I will argument why there is no bug, I will give some technical AND Methodology suggestions to fix or better model the use-case, and I will finally close the ticket as no bug is actually found.
Feel free to re-open if anything was not addressed fully.
h2. There is no bug
You wrote:
{quote}the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate{quote}
but this is not accurate.
Your actual expression is:
{code:java}
addend + Color Lookup[key=color].value
{code}
but {{Color Lookup[key=color].value}} is a projected feel:list<number> not a "single item"
In other words:
{noformat}
"filters" ? YES
"to a single item" ? NO
{noformat}
Then, because in FEEL adding a number to a list is not a valid operation, per DMN specification a null value is returned for "Add" decision.
{code:java}
Example:
1 + [2, 3] = null
{code}
This part of the model is behaving per DMN specification.
Coming to the "GetItem" and "Add2" part of the model, again all is working as expected, simply decision "GetItem" is defining the expected result type and the singleton list of String_Tuple is coerced to String_Tuple.
This part of the model is behaving per DMN specification.
h2. A purely technical solution
Rewrite the current "Add" literal expression
from:
{code:java}
addend + Color Lookup[key=color].value
{code}
to:
{code:java}
addend + Color Lookup[key=color].value[1]
{code}
this way you explicitly model the fact that the lookup shall return only a single number as the second operand of the arithmetic sum.
h2. A Methodology solution
In my perspective, it was lacking in the original modeling the fact that a lookup was meaning to return a single instance.
I believe this could be best modeled by encapsulating the logic of the look-up in a BKM "function":
!screenshot-1.png!
This way HOW the lookup is actually performed is properly encapsulated in a BKM.
Further, in my perspective is best to make the expectation explicit while implementing the BKM, like so:
!screenshot-2.png!
Finally, the use of this BKM in the "Add" decision for instance, is very natural:
!screenshot-3.png!
As based on the BKM signature it is explicit it is a function that take a feel:string and return a String_Tuple, which is accordingly to your original problem statement.
I hope this clarifies and helps!
> List Filter expression returning single item and nested within arithmetic expression fails to evaluate
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5280
> URL: https://issues.redhat.com/browse/DROOLS-5280
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.34.0.Final, 7.36.0.Final
> Reporter: Tracy Hires
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months
[JBoss JIRA] (DROOLS-5280) List Filter expression returning single item and nested within arithmetic expression fails to evaluate
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5280?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5280:
-----------------------------------
Attachment: screenshot-3.png
> List Filter expression returning single item and nested within arithmetic expression fails to evaluate
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5280
> URL: https://issues.redhat.com/browse/DROOLS-5280
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Affects Versions: 7.34.0.Final, 7.36.0.Final
> Reporter: Tracy Hires
> Assignee: Matteo Mortari
> Priority: Major
> Attachments: MySpace_Relation.zip, screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> the expression `addend + listOfStructure[field1="some value"].numberField`, where `field1="some value"` filters `listOfStructure` to a single item and `addend` and `numberField` are both non-null numbers, fails to evaluate. It's possible to work around this by placing `listOfStructure[field1="some value"]` into a separate decision.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months