[JBoss JIRA] (DROOLS-4534) ClassCastException using accumulate max in executable model
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4534?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-4534:
-----------------------------------
Assignee: Luca Molteni (was: Mario Fusco)
> ClassCastException using accumulate max in executable model
> -----------------------------------------------------------
>
> Key: DROOLS-4534
> URL: https://issues.jboss.org/browse/DROOLS-4534
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.26.0.Final
> Reporter: Martin Weiler
> Assignee: Luca Molteni
> Priority: Major
>
> A rule containing the following accumulate constraint:
> {noformat}
> $max1 : Number() from accumulate(
> StockTick($time : getTimeFieldAsDate());
> max($time.getTime()))
> {noformat}
> is successfully compiled using the executable model, but fails at runtime:
> {noformat}
> java.lang.RuntimeException: java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Long
> at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:105)
> at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> at org.drools.core.phreak.PhreakAccumulateNode.doLeftInserts(PhreakAccumulateNode.java:168)
> at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:89)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:581)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:552)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:379)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:339)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:175)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:133)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:213)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:88)
> at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34)
> at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1062)
> at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1009)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1001)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1330)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1321)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1305)
> at org.drools.modelcompiler.CompilerTest.testAccumulateWithMax(CompilerTest.java:2006)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (DROOLS-4532) Executable model compilation fails with java.lang.RuntimeException: Unknown expression type: -1
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4532?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-4532:
-----------------------------------
Assignee: Luca Molteni (was: Mario Fusco)
> Executable model compilation fails with java.lang.RuntimeException: Unknown expression type: -1
> -----------------------------------------------------------------------------------------------
>
> Key: DROOLS-4532
> URL: https://issues.jboss.org/browse/DROOLS-4532
> Project: Drools
> Issue Type: Bug
> Components: core engine, executable model
> Affects Versions: 7.26.0.Final
> Reporter: Martin Weiler
> Assignee: Luca Molteni
> Priority: Major
>
> A rule containing a function call with a negative argument:
> {noformat}
> eval( functions.add($age, -1).compareTo(10) < 0)
> {noformat}
> fails to compile when using the executable model:
> {noformat}
> java.lang.RuntimeException: Unknown expression type: -1
> at org.drools.modelcompiler.builder.generator.DrlxParseUtil.getExpressionType(DrlxParseUtil.java:245)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.processFirstNode(ExpressionTyper.java:562)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpressionFromMethodCallOrField(ExpressionTyper.java:380)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.parseNodeArguments(ExpressionTyper.java:679)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.parseMethodCallExpr(ExpressionTyper.java:647)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.methodCallExpr(ExpressionTyper.java:635)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpressionFromMethodCallOrField(ExpressionTyper.java:416)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpressionRec(ExpressionTyper.java:191)
> at org.drools.modelcompiler.builder.generator.expressiontyper.ExpressionTyper.toTypedExpression(ExpressionTyper.java:121)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.parseBinaryExpr(ConstraintParser.java:269)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.getDrlxParseResult(ConstraintParser.java:89)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.drlxParse(ConstraintParser.java:56)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.drlxParse(ConstraintParser.java:51)
> at org.drools.modelcompiler.builder.generator.drlxparse.ConstraintParser.drlxParse(ConstraintParser.java:47)
> at org.drools.modelcompiler.builder.generator.visitor.EvalVisitor.visit(EvalVisitor.java:25)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:94)
> at org.drools.compiler.lang.descr.EvalDescr.accept(EvalDescr.java:97)
> at org.drools.modelcompiler.builder.generator.visitor.AndVisitor.visit(AndVisitor.java:29)
> at org.drools.modelcompiler.builder.generator.visitor.ModelGeneratorVisitor.visit(ModelGeneratorVisitor.java:69)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.processRule(ModelGenerator.java:173)
> at org.drools.modelcompiler.builder.generator.ModelGenerator.generateModel(ModelGenerator.java:153)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.compileKnowledgePackages(ModelBuilderImpl.java:169)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildRules(ModelBuilderImpl.java:119)
> at org.drools.modelcompiler.builder.ModelBuilderImpl.buildPackages(ModelBuilderImpl.java:69)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:108)
> at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:100)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.buildKnowledgePackages(AbstractKieProject.java:261)
> at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:75)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:271)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:239)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:208)
> at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:196)
> at org.drools.modelcompiler.BaseModelTest.createKieBuilder(BaseModelTest.java:144)
> at org.drools.modelcompiler.BaseModelTest.createKieBuilder(BaseModelTest.java:125)
> at org.drools.modelcompiler.BaseModelTest.getKieContainer(BaseModelTest.java:114)
> at org.drools.modelcompiler.BaseModelTest.getKieContainer(BaseModelTest.java:107)
> at org.drools.modelcompiler.BaseModelTest.getKieSession(BaseModelTest.java:103)
> at org.drools.modelcompiler.BaseModelTest.getKieSession(BaseModelTest.java:99)
> at org.drools.modelcompiler.CompilerTest.testEvalExprWithFunctionCall(CompilerTest.java:1997)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFWIP-198) Operator long-term strategy
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ]
Martin Choma edited comment on WFWIP-198 at 9/16/19 2:39 AM:
-------------------------------------------------------------
So if I understand you correctly you are saying your preference is 2. Problem is EAP7-1192 wont permit turn off operator for people using transaction.
So when user find himself in situation he need option which Operator does not expose, he will raise RFE and wait couple of months to be delivered. I assume over a time customers will come with request to expose nearly all internal Kubernetes objects options. Which will mean Operator will expose all options, but that will be in your words "disaster from a usability and maintenance point of view". And I agree.
>From my point of view best would be to decoupled EAP7-1192 (and any other future feature) from operator codebase. So user can turn off operator without loosing any EAP capability. And keep small set of most useful options for operator.
"we need to make sure that the Operator is able to do all the things that we currently support" Now the question is how we define "we".
- Is it just what EAP document and test?
- Or also what OpenShift document and test?
For example EAP do not document neither test pod.spec.imagePullSecrets option. It is documented by OpenShift documentation [1] so supported by RedHat. So should we add this option to Operator in this stage?
[1] https://docs.openshift.com/container-platform/3.11/rest_api/api/v1.Pod.html
was (Author: mchoma):
So if I understand you correctly you are saying your preference is 2. Problem is EAP7-1192 wont permit turn off operator for people using transaction.
So when user find himself in situation he need option which Operator does not expose, he will raise RFE and wait couple of months to be delivered. I assume over a time customers will come with request to expose nearly all internal Kubernetes objects options. Which will mean Operator will expose all options, but that will be in your words "disaster from a usability and maintenance point of view". And I agree.
>From my point of view best would be to decoupled EAP7-1192 (and any other future feature) from operator codebase. So user can turn off operator without loosing any EAP capability. And keep small set of most useful options for operator.
"we need to make sure that the Operator is able to do all the things that we currently support" Now the question is how we define "we".
- Is it just what EAP document and test?
- Or also what OpenShift document and test?
For example EAP do not document neither test pod.spec.imagePullSecrets option. It is documented by OpenShift documentation so supported by RedHat. So should we add this option to Operator in this stage?
[1] https://docs.openshift.com/container-platform/3.11/rest_api/api/v1.Pod.html
> Operator long-term strategy
> ---------------------------
>
> Key: WFWIP-198
> URL: https://issues.jboss.org/browse/WFWIP-198
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Facts:
> # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1].
> # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work.
> # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime.
> So given these facts question is what is long-term strategy with Operator?
> # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator
> # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192)
> # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?)
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wil...
> [2]
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFWIP-198) Operator long-term strategy
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ]
Martin Choma edited comment on WFWIP-198 at 9/16/19 2:39 AM:
-------------------------------------------------------------
So if I understand you correctly you are saying your preference is 2. Problem is EAP7-1192 wont permit turn off operator for people using transaction.
So when user find himself in situation he need option which Operator does not expose, he will raise RFE and wait couple of months to be delivered. I assume over a time customers will come with request to expose nearly all internal Kubernetes objects options. Which will mean Operator will expose all options, but that will be in your words "disaster from a usability and maintenance point of view". And I agree.
>From my point of view best would be to decoupled EAP7-1192 (and any other future feature) from operator codebase. So user can turn off operator without loosing any EAP capability. And keep small set of most useful options for operator.
"we need to make sure that the Operator is able to do all the things that we currently support" Now the question is how we define "we".
- Is it just what EAP document and test?
- Or also what OpenShift document and test?
For example EAP do not document neither test pod.spec.imagePullSecrets option. It is documented by OpenShift documentation so supported by RedHat. So should we add this option to Operator in this stage?
[1] https://docs.openshift.com/container-platform/3.11/rest_api/api/v1.Pod.html
was (Author: mchoma):
So if I understand you correctly you are saying your preference is 2. Problem is EAP7-1192 wont permit turn off operator for people using transaction.
So when user find himself in situation he need option which Operator does not expose, he will raise RFE and wait couple of months to be delivered. I assume over a time customers will come with request to expose nearly all internal Kubernetes objects options. Which will mean Operator will expose all options, but that will be in your words "disaster from a usability and maintenance point of view". And I agree.
>From my point of view best would be to decoupled EAP7-1192 (and any other future feature) from operator codebase. So user can turn off operator without loosing any EAP capability. And keep small set of most useful options for operator.
"we need to make sure that the Operator is able to do all the things that we currently support"
- now the question is how we define "we".
-- Is it just what EAP document and test?
-- Or also what OpenShift document and test?
For example EAP do not document neither test pod.spec.imagePullSecrets option. It is documented by OpenShift documentation so supported by RedHat. So should we add this option to Operator in this stage?
[1] https://docs.openshift.com/container-platform/3.11/rest_api/api/v1.Pod.html
> Operator long-term strategy
> ---------------------------
>
> Key: WFWIP-198
> URL: https://issues.jboss.org/browse/WFWIP-198
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Facts:
> # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1].
> # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work.
> # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime.
> So given these facts question is what is long-term strategy with Operator?
> # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator
> # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192)
> # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?)
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wil...
> [2]
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFWIP-198) Operator long-term strategy
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ]
Martin Choma edited comment on WFWIP-198 at 9/16/19 2:39 AM:
-------------------------------------------------------------
So if I understand you correctly you are saying your preference is 2. Problem is EAP7-1192 wont permit turn off operator for people using transaction.
So when user find himself in situation he need option which Operator does not expose, he will raise RFE and wait couple of months to be delivered. I assume over a time customers will come with request to expose nearly all internal Kubernetes objects options. Which will mean Operator will expose all options, but that will be in your words "disaster from a usability and maintenance point of view". And I agree.
>From my point of view best would be to decoupled EAP7-1192 (and any other future feature) from operator codebase. So user can turn off operator without loosing any EAP capability. And keep small set of most useful options for operator.
"we need to make sure that the Operator is able to do all the things that we currently support" Now the question is how we define "we".
- Is it just what EAP document and test?
- Or also what OpenShift document and test?
For example EAP do not document neither test pod.spec.imagePullSecrets option. It is documented by OpenShift documentation so supported by RedHat. So should we add this option to Operator in this stage?
[1] https://docs.openshift.com/container-platform/3.11/rest_api/api/v1.Pod.html
was (Author: mchoma):
So if I understand you correctly you are saying your preference is 2. Problem is EAP7-1192 wont permit turn off operator for people using transaction.
So when user find himself in situation he need option which Operator does not expose, he will raise RFE and wait couple of months to be delivered. I assume over a time customers will come with request to expose nearly all internal Kubernetes objects options. Which will mean Operator will expose all options, but that will be in your words "disaster from a usability and maintenance point of view". And I agree.
>From my point of view best would be to decoupled EAP7-1192 (and any other future feature) from operator codebase. So user can turn off operator without loosing any EAP capability. And keep small set of most useful options for operator.
"we need to make sure that the Operator is able to do all the things that we currently support" Now the question is how we define "we".
- Is it just what EAP document and test?
- Or also what OpenShift document and test?
For example EAP do not document neither test pod.spec.imagePullSecrets option. It is documented by OpenShift documentation so supported by RedHat. So should we add this option to Operator in this stage?
[1] https://docs.openshift.com/container-platform/3.11/rest_api/api/v1.Pod.html
> Operator long-term strategy
> ---------------------------
>
> Key: WFWIP-198
> URL: https://issues.jboss.org/browse/WFWIP-198
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Facts:
> # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1].
> # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work.
> # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime.
> So given these facts question is what is long-term strategy with Operator?
> # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator
> # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192)
> # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?)
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wil...
> [2]
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFWIP-198) Operator long-term strategy
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-198?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFWIP-198:
------------------------------------
So if I understand you correctly you are saying your preference is 2. Problem is EAP7-1192 wont permit turn off operator for people using transaction.
So when user find himself in situation he need option which Operator does not expose, he will raise RFE and wait couple of months to be delivered. I assume over a time customers will come with request to expose nearly all internal Kubernetes objects options. Which will mean Operator will expose all options, but that will be in your words "disaster from a usability and maintenance point of view". And I agree.
>From my point of view best would be to decoupled EAP7-1192 (and any other future feature) from operator codebase. So user can turn off operator without loosing any EAP capability. And keep small set of most useful options for operator.
"we need to make sure that the Operator is able to do all the things that we currently support"
- now the question is how we define "we".
-- Is it just what EAP document and test?
-- Or also what OpenShift document and test?
For example EAP do not document neither test pod.spec.imagePullSecrets option. It is documented by OpenShift documentation so supported by RedHat. So should we add this option to Operator in this stage?
[1] https://docs.openshift.com/container-platform/3.11/rest_api/api/v1.Pod.html
> Operator long-term strategy
> ---------------------------
>
> Key: WFWIP-198
> URL: https://issues.jboss.org/browse/WFWIP-198
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> Facts:
> # Operator creates and manges internaly several kubernetes objects; StatefulSet, Pod, Service, Routes. By rough estimation these kubernetes objects expose approximately 50 options[2]. Operator now expose approximately 10 options [1].
> # EAP7-1192 is currently designed in way operator is integral part of solution. You can not turn off operator to EAP7-1192 properly work.
> # User cant touch internal Kubernetes objects. Operator manages them and can overwrite changes anytime.
> So given these facts question is what is long-term strategy with Operator?
> # Operator will provide all options of internal objects. Everything I am able to configure directly with Kubernetes objects I will be able to configure with Operator
> # Operator will expose just most useful options. If user wants to make something special he has to "turn off" operator and to be on his own. (Loosing transaction support provided by EAP7-1192)
> # Operator will expose just most useful options. If user wants to make something special he can and Operator won't overwritten his changes. (I dont know if it is feasible?)
> [1] https://github.com/wildfly/wildfly-operator/blob/master/doc/apis.adoc#wil...
> [2]
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#pods...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#stat...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#serv...
> https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.15/#ingr...
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (DROOLS-4536) Test scenarios fails with default values
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-4536?page=com.atlassian.jira.plugi... ]
Toni Rikkola moved JBPM-8703 to DROOLS-4536:
--------------------------------------------
Project: Drools (was: jBPM)
Key: DROOLS-4536 (was: JBPM-8703)
Component/s: Test Scenarios Editor
(was: Workbench)
Affects Version/s: 7.25.0.Final
(was: 7.25.0.Final)
> Test scenarios fails with default values
> ----------------------------------------
>
> Key: DROOLS-4536
> URL: https://issues.jboss.org/browse/DROOLS-4536
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.25.0.Final
> Reporter: Sudhish Nair
> Assignee: Toni Rikkola
> Priority: Minor
> Labels: drools-tools, support
> Attachments: latestjbpmfailed.png, latestjbpmpassed.png
>
>
> In test scenarios (Legacy test scenario) expect section, if we don't edit the default numeric values in expect section then test scenario fails, but if we edit and enter the same value it passes, sometimes we have to type a different value, run the test, then retype 0/0.0 for it to pass.
> The issue is always reproducible.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months