August 2017 - jboss-jira - Jboss List Archives

[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, 4 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, 4 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, 4 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, 4 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, 4 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, 4 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: 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. 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? > [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 > > 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. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 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 moved JBEAP-12480 to WFCORE-3133: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-3133 (was: JBEAP-12480) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Migration) (was: Web (Undertow)) Affects Version/s: 3.0.0.Beta30 (was: 7.0.0.DR9) > [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 > > 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, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Jason Greene resolved WFLY-5413. -------------------------------- Fix Version/s: 11.0.0.Beta1 (was: 11.0.0.CR1) Resolution: Done > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondra Chaloupka > Assignee: Tomasz Adamski > Fix For: 11.0.0.Beta1 > > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Jason Greene reopened WFLY-5413: -------------------------------- reopening to change fix version > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondra Chaloupka > Assignee: Tomasz Adamski > Fix For: 11.0.0.Beta1 > > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017