January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4974) Introduce KafkaStream API into HACep

by Massimiliano Dessi (Jira)

Massimiliano Dessi created DROOLS-4974: ------------------------------------------ Summary: Introduce KafkaStream API into HACep Key: DROOLS-4974 URL: https://issues.redhat.com/browse/DROOLS-4974 Project: Drools Issue Type: Feature Request Reporter: Massimiliano Dessi Assignee: Massimiliano Dessi -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4473) Testing DefaultKafkaConsumer

by Massimiliano Dessi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4473?page=com.atlassian.jira.plug... ] Massimiliano Dessi closed DROOLS-4473. -------------------------------------- Resolution: Won't Fix > Testing DefaultKafkaConsumer > ----------------------------- > > Key: DROOLS-4473 > URL: https://issues.redhat.com/browse/DROOLS-4473 > Project: Drools > Issue Type: Task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > Labels: HADrools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-4956: -------------------------------------- Description: Having a constraint like {code:java} Person($customer == name) {code} is not really the same thing as {code:java} Person(name == $customer) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. was: Having a constraint like {code:java} Person( name == "Toshiya" ) {code} is not really the same thing as {code:java} Person( "Toshiya" == name ) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person($customer == name) > {code} > is not really the same thing as > {code:java} > Person(name == $customer) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 5:01 AM: -------------------------------------------------------------------- Note: {code:java} Person( "Toshiya" == name ) {code} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). was (Author: tkobayashi): Note: {code:java} Person( "Toshiya" == name ) {code} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code} This can cause a property reactivity issue. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person($customer == name) > {code} > is not really the same thing as > {code:java} > Person(name == $customer) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-4956: -------------------------------------- Description: Having a constraint like {code:java} Person(name == $customer) {code} is not really the same thing as {code:java} Person($customer == name) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. was: Having a constraint like {code:java} Person($customer == name) {code} is not really the same thing as {code:java} Person(name == $customer) {code} In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person(name == $customer) > {code} > is not really the same thing as > {code:java} > Person($customer == name) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 4:59 AM: -------------------------------------------------------------------- Note: {code:java} Person( "Toshiya" == name ) {code:java} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code:java} This can cause a property reactivity issue. was (Author: tkobayashi): Note: Person( "Toshiya" == name ) works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person( name == "Toshiya" ) > {code} > is not really the same thing as > {code:java} > Person( "Toshiya" == name ) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi edited comment on DROOLS-4956 at 1/24/20 5:00 AM: -------------------------------------------------------------------- Note: {code:java} Person( "Toshiya" == name ) {code} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code} This can cause a property reactivity issue. was (Author: tkobayashi): Note: {code:java} Person( "Toshiya" == name ) {code:java} works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). {code:java} Person($customer == name) {code:java} This can cause a property reactivity issue. > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person( name == "Toshiya" ) > {code} > is not really the same thing as > {code:java} > Person( "Toshiya" == name ) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4956) Normarize rule constraints for property reactivity and indexing

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4956?page=com.atlassian.jira.plug... ] Toshiya Kobayashi commented on DROOLS-4956: ------------------------------------------- Note: Person( "Toshiya" == name ) works for property reactivity thanks to MvelConstraint.getPropertyNameFromSimpleExpression()/StringUtils.extractFirstIdentifier() which intelligently detects the property name. However, it doesn't work for indexing because CompositeObjectSinkAdapter.isHashable() returns false (indexableConstraint.fieldValue == null in this case). > Normarize rule constraints for property reactivity and indexing > --------------------------------------------------------------- > > Key: DROOLS-4956 > URL: https://issues.redhat.com/browse/DROOLS-4956 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Affects Versions: 7.31.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Having a constraint like > {code:java} > Person( name == "Toshiya" ) > {code} > is not really the same thing as > {code:java} > Person( "Toshiya" == name ) > {code} > In the second case not only you don't have property reactivity, but also you don't have indexing. This an inconsistent behaviour and hoping to fix it with a "normalization" phase where the second constraint got rewritten like the first before being analyzed by property reactivity and indexing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4973) Defined collection unary checks do not pass

by Jozef Marko (Jira)

Jozef Marko created DROOLS-4973: ----------------------------------- Summary: Defined collection unary checks do not pass Key: DROOLS-4973 URL: https://issues.redhat.com/browse/DROOLS-4973 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Affects Versions: 7.32.0.Final Reporter: Jozef Marko Assignee: Daniele Zonca Attachments: MySpace_eshop.zip Import the attached project and click Build, then Test. The re are defined 2 groups of 2 equivalent tests. In each group one test has a collection unary check defined with UI editor and one test defined a collection unary check with textual editor. The issue is tests with the unary check defined via textual editor do not pass. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4698: ------------------------------------- New issue https://issues.redhat.com/browse/DROOLS-4973 > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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 January 2020