August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1687) NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects()

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1687?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1687: ------------------------------------------ Mario and I had a meeting, we decided to *fail fast with a helpful error message (including accumulate name and hopefully rule name etc)* and Mario will create a new jira linked here to have *the min/max functions also have reverseSupport if and only if a flag is true on the KieSession*. Raw meeting notes: {code} A) return empty list // ge0ffrey: -1 (user doesn't know) B) log warning; return empty list C) Fail fast // ge0ffrey +1 throw UnsupportedOperationException "The justification failed because the accumulate function (max) in rule (my hard constraint) on line 72 in foo.drl does not have reverseSupport" D) minWithReverseSupport, maxWithReverseSupport con: users don't care and have to make a choice up front E) min and max have reverseSupport always con: performance loss? how much? F) Can we do E) with a flag on the KieBase? drools.setProperty("giveMinMaxReverseSupport" = true) G) Can we do E) with a flag on the KieSession? drools.setProperty("giveMinMaxReverseSupport" = true) // OptaPlanner knows for each KieSession if it needs justification or not (= constraintMatchEnabled = true) Proposal: C) in case they use a custom function without reverseSupport G) so C) doesn't happen much {code} > NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects() > ------------------------------------------------------------- > > Key: DROOLS-1687 > URL: https://issues.jboss.org/browse/DROOLS-1687 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Jiri Locker > Assignee: Mario Fusco > Attachments: DroolsReproducerTest.java > > > Based on https://stackoverflow.com/questions/45161751/get-broken-constrains-in-opt.... > {code} > Exception executing consequence for rule "requiredCpuPowerTotal" in testpkg: java.lang.NullPointerException > at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) > ... > Caused by: java.lang.NullPointerException > at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor$JavaAccumulatorFunctionContext.getAccumulatedObjects(JavaAccumulatorFunctionExecutor.java:208) > at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:94) > at org.drools.core.common.AgendaItem.getObjectsDeep(AgendaItem.java:79) > at org.drools.core.reteoo.RuleTerminalNodeLeftTuple.getObjectsDeep(RuleTerminalNodeLeftTuple.java:359) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3134) When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description.

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3134?page=com.atlassian.jira.plugi... ] Jiri Ondrusek moved JBEAP-12483 to WFCORE-3134: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3134 (was: JBEAP-12483) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) (was: User Experience) Affects Version/s: 3.0.0.Beta30 (was: 7.1.0.DR19) > When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description. > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3134 > URL: https://issues.jboss.org/browse/WFCORE-3134 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta30 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > Labels: eap72 > > When is operation add-alias run more times for same alias name then is displayed \" instead of only " in failure description. > There is expected quotation without backslash in failure description. > *How to reproduce* > *create credential store* > {code} > /subsystem=elytron/credential-store=cs001:add(create=true, credential-reference={clear-text=pass123},location=cs001.jceks) > {code} > *Try to add-alias twice and for second run you get failure description.* > {code} > /subsystem=elytron/credential-store=cs001:add-alias(alias=alias001, secret-value="secret_value") > /subsystem=elytron/credential-store=cs001:add-alias(alias=alias001, secret-value="secret_value") > { > "outcome" => "failed", > "result" => undefined, > "failure-description" => "WFLYELY00913: Credential alias \"alias001\" of credential type \"org.wildfly.security.credential.PasswordCredential\" already exists in the store", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1687) NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects()

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1687?page=com.atlassian.jira.plugi... ] Jiri Locker updated DROOLS-1687: -------------------------------- Summary: NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects() (was: NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects) > NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects() > ------------------------------------------------------------- > > Key: DROOLS-1687 > URL: https://issues.jboss.org/browse/DROOLS-1687 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Jiri Locker > Assignee: Mario Fusco > Attachments: DroolsReproducerTest.java > > > Based on https://stackoverflow.com/questions/45161751/get-broken-constrains-in-opt.... > {code} > Exception executing consequence for rule "requiredCpuPowerTotal" in testpkg: java.lang.NullPointerException > at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) > ... > Caused by: java.lang.NullPointerException > at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor$JavaAccumulatorFunctionContext.getAccumulatedObjects(JavaAccumulatorFunctionExecutor.java:208) > at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:94) > at org.drools.core.common.AgendaItem.getObjectsDeep(AgendaItem.java:79) > at org.drools.core.reteoo.RuleTerminalNodeLeftTuple.getObjectsDeep(RuleTerminalNodeLeftTuple.java:359) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1688) A rule does not fire when String type coercion used in its pattern

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1688?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-1688: ---------------------------------- Description: Having a test like this [1], only one rule fires. When the rule R1 is commented out, 2 rules fire. I will create a PR with this reproducer. [1] https://gist.github.com/baldimir/8a1d50fa29401cec127c694ade6c225b was: Having a test like this [1], only one rule fires. When the order of the rules R2 and R3 is switched, 2 rules fire. I will create a PR with this reproducer. [1] https://gist.github.com/baldimir/8a1d50fa29401cec127c694ade6c225b > A rule does not fire when String type coercion used in its pattern > ------------------------------------------------------------------ > > Key: DROOLS-1688 > URL: https://issues.jboss.org/browse/DROOLS-1688 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Fix For: 7.2.0.Final > > > Having a test like this [1], only one rule fires. When the rule R1 is commented out, 2 rules fire. I will create a PR with this reproducer. > [1] https://gist.github.com/baldimir/8a1d50fa29401cec127c694ade6c225b -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1688) A rule does not fire when String type coercion used in its pattern

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1688?page=com.atlassian.jira.plugi... ] Tibor Zimányi commented on DROOLS-1688: --------------------------------------- PR here: https://github.com/kiegroup/drools/pull/1404 > A rule does not fire when String type coercion used in its pattern > ------------------------------------------------------------------ > > Key: DROOLS-1688 > URL: https://issues.jboss.org/browse/DROOLS-1688 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Fix For: 7.2.0.Final > > > Having a test like this [1], only one rule fires. When the order of the rules R2 and R3 is switched, 2 rules fire. I will create a PR with this reproducer. > [1] https://gist.github.com/baldimir/8a1d50fa29401cec127c694ade6c225b -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1688) A rule does not fire when String type coercion used in its pattern

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1688: ------------------------------------- Summary: A rule does not fire when String type coercion used in its pattern Key: DROOLS-1688 URL: https://issues.jboss.org/browse/DROOLS-1688 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.1.0.Final Reporter: Tibor Zimányi Assignee: Mario Fusco Fix For: 7.2.0.Final Having a test like this [1], only one rule fires. When the order of the rules R2 and R3 is switched, 2 rules fire. I will create a PR with this reproducer. [1] https://gist.github.com/baldimir/8a1d50fa29401cec127c694ade6c225b -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1687) NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1687?page=com.atlassian.jira.plugi... ] Jiri Locker updated DROOLS-1687: -------------------------------- Stackoverflow ID: (was: 45161751) > NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects > ----------------------------------------------------------- > > Key: DROOLS-1687 > URL: https://issues.jboss.org/browse/DROOLS-1687 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Jiri Locker > Assignee: Mario Fusco > Attachments: DroolsReproducerTest.java > > > {code} > Exception executing consequence for rule "requiredCpuPowerTotal" in testpkg: java.lang.NullPointerException > at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) > ... > Caused by: java.lang.NullPointerException > at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor$JavaAccumulatorFunctionContext.getAccumulatedObjects(JavaAccumulatorFunctionExecutor.java:208) > at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:94) > at org.drools.core.common.AgendaItem.getObjectsDeep(AgendaItem.java:79) > at org.drools.core.reteoo.RuleTerminalNodeLeftTuple.getObjectsDeep(RuleTerminalNodeLeftTuple.java:359) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1687) NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1687?page=com.atlassian.jira.plugi... ] Jiri Locker updated DROOLS-1687: -------------------------------- Description: Based on https://stackoverflow.com/questions/45161751/get-broken-constrains-in-opt.... {code} Exception executing consequence for rule "requiredCpuPowerTotal" in testpkg: java.lang.NullPointerException at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) ... Caused by: java.lang.NullPointerException at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor$JavaAccumulatorFunctionContext.getAccumulatedObjects(JavaAccumulatorFunctionExecutor.java:208) at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:94) at org.drools.core.common.AgendaItem.getObjectsDeep(AgendaItem.java:79) at org.drools.core.reteoo.RuleTerminalNodeLeftTuple.getObjectsDeep(RuleTerminalNodeLeftTuple.java:359) {code} was: {code} Exception executing consequence for rule "requiredCpuPowerTotal" in testpkg: java.lang.NullPointerException at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) ... Caused by: java.lang.NullPointerException at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor$JavaAccumulatorFunctionContext.getAccumulatedObjects(JavaAccumulatorFunctionExecutor.java:208) at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:94) at org.drools.core.common.AgendaItem.getObjectsDeep(AgendaItem.java:79) at org.drools.core.reteoo.RuleTerminalNodeLeftTuple.getObjectsDeep(RuleTerminalNodeLeftTuple.java:359) {code} > NPE in JavaAccumulatorFunctionContext.getAccumulatedObjects > ----------------------------------------------------------- > > Key: DROOLS-1687 > URL: https://issues.jboss.org/browse/DROOLS-1687 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.1.0.Final > Reporter: Jiri Locker > Assignee: Mario Fusco > Attachments: DroolsReproducerTest.java > > > Based on https://stackoverflow.com/questions/45161751/get-broken-constrains-in-opt.... > {code} > Exception executing consequence for rule "requiredCpuPowerTotal" in testpkg: java.lang.NullPointerException > at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39) > ... > Caused by: java.lang.NullPointerException > at org.drools.core.base.accumulators.JavaAccumulatorFunctionExecutor$JavaAccumulatorFunctionContext.getAccumulatedObjects(JavaAccumulatorFunctionExecutor.java:208) > at org.drools.core.reteoo.FromNodeLeftTuple.getAccumulatedObjects(FromNodeLeftTuple.java:94) > at org.drools.core.common.AgendaItem.getObjectsDeep(AgendaItem.java:79) > at org.drools.core.reteoo.RuleTerminalNodeLeftTuple.getObjectsDeep(RuleTerminalNodeLeftTuple.java:359) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3133) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3133?page=com.atlassian.jira.plugi... ] Jiri Ondrusek updated WFCORE-3133: ---------------------------------- Description: Part of solution for: https://issues.jboss.org/browse/WFLY-9155. Server has to be able to start after such migration -> with empty keystore password. --- In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. Does it really make sense to require it? In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? was: In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. Does it really make sense to require it? In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? Server has to be able to start after such migration -> with empty keystore password. > [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory? > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-3133 > URL: https://issues.jboss.org/browse/WFCORE-3133 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.0.Beta30 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > Part of solution for: https://issues.jboss.org/browse/WFLY-9155. > Server has to be able to start after such migration -> with empty keystore password. > --- > In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. > Does it really make sense to require it? > In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9155) [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory?

by Jiri Ondrusek (JIRA)

[ https://issues.jboss.org/browse/WFLY-9155?page=com.atlassian.jira.plugin.... ] Jiri Ondrusek updated WFLY-9155: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10381 (was: https://github.com/wildfly/wildfly/pull/10381, https://github.com/wildfly/wildfly-core/pull/2680) > [Migration operation] [Web to Undertow] truststore - keystore-password does it really needs to be mandatory? > ------------------------------------------------------------------------------------------------------------ > > Key: WFLY-9155 > URL: https://issues.jboss.org/browse/WFLY-9155 > Project: WildFly > Issue Type: Bug > Affects Versions: 11.0.0.Beta1 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > > In WildFly there is required to set keystore-password for truststore even though at least in case of JKS, it is possible to read public certificates even without providing the password. > Does it really make sense to require it? > In regards to migration operation, wouldn't it make sense in case of undefined {{ca-certificate-password}} to provide the security-realm truststore configuration default value "changeit" instead of failing the whole migrate operation? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017