December 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-365) Rule attribute for adding inverse of consequence as rule condition

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-365?page=com.atlassian.jira.plugin... ] Davide Sottara edited comment on DROOLS-365 at 12/7/13 5:56 PM: ---------------------------------------------------------------- I see your use case. Here is another possible way to do it. If you like it, we may work on getting it into master by default. We need the notion of "Undercutting", borrowed from non-monotonic logic. This is the core idea, to be expanded on as needed. Imagine you have two rules potentially triggered by the same object(s), and you want one to take precedence over the other. Use an annotation like @Undercuts in the first, passing the name of the other rule as an argument. {code} rule "handle all Bars of type second" @Undercuts( others ) when $bar : Bar( type == 'second', $total : total ) then System.out.println( "Second bars " + $total ); end rule "others" when $bar : Bar( $total : total ) then System.out.println( "Other bars " + $total ); end {code} In the main, enable the declarative agenda: {code} knowledgeBaseConfiguration.setOption( DeclarativeAgendaOption.ENABLED ); {code} And finally add a "utility" rule. This rule is generic, but its purpose is to enable the desired functionality: {code} rule "Undercut" @activationListener('direct') when $m : Match( $handles : factHandles ) $v : Match( rule.name == $m.Undercuts, factHandles == $handles ) then System.out.println( "Activation of rule " + $m.getRule().getName() + " overrides " + $v.getRule().getName() + " for tuple " + $handles ); kcontext.cancelMatch( $v ); end {code} Let me know if this would be enough for your concrete use case. Important : I fixed a bug while creating the test, so it won't work until my PR is merged on Monday Davide was (Author: dsotty): I see your use case. Here is another possible way to do it. If you like it, we may work on getting it into master by default. We need the notion of "Undercutting", borrowed from non-monotonic logic. This is the core idea, to be expanded on as needed. Imagine you have two rules potentially triggered by the same object(s), and you want one to take precedence over the other. Use an annotation like @Undercuts in the first, passing the name of the other rule as an argument. {code} rule "handle all Bars of type second" @Undercuts( others ) when $bar : Bar( type == 'second', $total : total ) then System.out.println( "Second bars " + $total ); end rule "others" when $bar : Bar( $total : total ) then System.out.println( "Other bars " + $total ); end {code} In the main, enable the declarative agenda: {code} knowledgeBaseConfiguration.setOption( DeclarativeAgendaOption.ENABLED ); {code} And finally add a "utility" rule. This rule is generic, but its purpose is to enable the desired functionality: {code} rule "Undercut" @activationListener('direct') when $m : Match( $handles : factHandles ) $v : Match( rule.name == $m.Undercuts, factHandles == $handles ) then System.out.println( "Activation of rule " + $m.getRule().getName() + " overrides " + $v.getRule().getName() + " for tuple " + $handles ); kcontext.cancelMatch( $v ); end {code} Let me know if this would be enough for your concrete use case. Davide > Rule attribute for adding inverse of consequence as rule condition > ------------------------------------------------------------------ > > Key: DROOLS-365 > URL: https://issues.jboss.org/browse/DROOLS-365 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Adar Dembo > Assignee: Mark Proctor > > I have quite a few rules that look like this: > {noformat} > rule "if foo then bar" > when > Foo($a : a, $b : b) > not Bar(a == $a, b == $b) > then > insert(new Bar($a, $b)); > end > {noformat} > This is a fairly common pattern for me: a rule should not activate if the facts generated by its consequence were already asserted. It's a pattern I use extensively to generate linear (i.e. non-repeating) workflows. > Ideally I'd be able to express it as follows: > {noformat} > rule "if foo then bar" > condition-on-inverse-of-consequence > when > Foo($a : a, $b : b) > then > insert(new Bar($a, $b)); > end > {noformat} > And {{condition-on-inverse-of-consequence}} would cause Drools to generate the right kind of condition, which would be the inverse of the fact changes made by the consequence. > I think {{lock-on-active}} is similar but harsher: it prevents the rule from firing a second time altogether, regardless of input. At least, that's based on my reading of the docs. In my example, that would be equivalent to {{not Bar()}} condition in the rule, which is stricter than {{not Bar(a == $a, b == $b)}}. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-365) Rule attribute for adding inverse of consequence as rule condition

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-365?page=com.atlassian.jira.plugin... ] Davide Sottara edited comment on DROOLS-365 at 12/7/13 5:55 PM: ---------------------------------------------------------------- I see your use case. Here is another possible way to do it. If you like it, we may work on getting it into master by default. We need the notion of "Undercutting", borrowed from non-monotonic logic. This is the core idea, to be expanded on as needed. Imagine you have two rules potentially triggered by the same object(s), and you want one to take precedence over the other. Use an annotation like @Undercuts in the first, passing the name of the other rule as an argument. {code} rule "handle all Bars of type second" @Undercuts( others ) when $bar : Bar( type == 'second', $total : total ) then System.out.println( "Second bars " + $total ); end rule "others" when $bar : Bar( $total : total ) then System.out.println( "Other bars " + $total ); end {code} In the main, enable the declarative agenda: {code} knowledgeBaseConfiguration.setOption( DeclarativeAgendaOption.ENABLED ); {code} And finally add a "utility" rule. This rule is generic, but its purpose is to enable the desired functionality: {code} rule "Undercut" @activationListener('direct') when $m : Match( $handles : factHandles ) $v : Match( rule.name == $m.Undercuts, factHandles == $handles ) then System.out.println( "Activation of rule " + $m.getRule().getName() + " overrides " + $v.getRule().getName() + " for tuple " + $handles ); kcontext.cancelMatch( $v ); end {code} Let me know if this would be enough for your concrete use case. Davide was (Author: dsotty): I see your use case. Here is another possible way to do it. If you like it, we may work on getting it into master by default. We need the notion of "Undercutting", borrowed from non-monotonic logic. This is the core idea, to be expanded on as needed. Imagine you have two rules potentially triggered by the same object(s), and you want one to take precedence over the other. Use an annotation like @Undercuts in the first, passing the name of the other rule as an argument. {code} rule "handle all Bars of type second" @Undercuts( others ) when $bar : Bar( type == 'second', $total : total ) then System.out.println( "Second bars " + $total ); end rule "others" when $bar : Bar( $total : total ) then System.out.println( "Other bars " + $total ); end {code} In the main, enable the declarative agenda: {code} knowledgeBaseConfiguration.setOption( DeclarativeAgendaOption.ENABLED ); {code} And finally add a "utility" rule. This rule is generic, but its purpose is to enable the desired functionality: {code} rule "Undercut" salience 9999 // should have max priority when $m : Match( $handles : factHandles ) $v : Match( rule.name == $m.Undercuts, factHandles == $handles ) then System.out.println( "Activation of rule " + $m.getRule().getName() + " overrides " + $v.getRule().getName() + " for tuple " + $handles ); kcontext.cancelMatch( $v ); end {code} Let me know if this would be enough for your concrete use case. Davide > Rule attribute for adding inverse of consequence as rule condition > ------------------------------------------------------------------ > > Key: DROOLS-365 > URL: https://issues.jboss.org/browse/DROOLS-365 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Adar Dembo > Assignee: Mark Proctor > > I have quite a few rules that look like this: > {noformat} > rule "if foo then bar" > when > Foo($a : a, $b : b) > not Bar(a == $a, b == $b) > then > insert(new Bar($a, $b)); > end > {noformat} > This is a fairly common pattern for me: a rule should not activate if the facts generated by its consequence were already asserted. It's a pattern I use extensively to generate linear (i.e. non-repeating) workflows. > Ideally I'd be able to express it as follows: > {noformat} > rule "if foo then bar" > condition-on-inverse-of-consequence > when > Foo($a : a, $b : b) > then > insert(new Bar($a, $b)); > end > {noformat} > And {{condition-on-inverse-of-consequence}} would cause Drools to generate the right kind of condition, which would be the inverse of the fact changes made by the consequence. > I think {{lock-on-active}} is similar but harsher: it prevents the rule from firing a second time altogether, regardless of input. At least, that's based on my reading of the docs. In my example, that would be equivalent to {{not Bar()}} condition in the rule, which is stricter than {{not Bar(a == $a, b == $b)}}. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-365) Rule attribute for adding inverse of consequence as rule condition

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-365?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-365: --------------------------------------- I see your use case. Here is another possible way to do it. If you like it, we may work on getting it into master by default. We need the notion of "Undercutting", borrowed from non-monotonic logic. This is the core idea, to be expanded on as needed. Imagine you have two rules potentially triggered by the same object(s), and you want one to take precedence over the other. Use an annotation like @Undercuts in the first, passing the name of the other rule as an argument. {code} rule "handle all Bars of type second" @Undercuts( others ) when $bar : Bar( type == 'second', $total : total ) then System.out.println( "Second bars " + $total ); end rule "others" when $bar : Bar( $total : total ) then System.out.println( "Other bars " + $total ); end {code} In the main, enable the declarative agenda: {code} knowledgeBaseConfiguration.setOption( DeclarativeAgendaOption.ENABLED ); {code} And finally add a "utility" rule. This rule is generic, but its purpose is to enable the desired functionality: {code} rule "Undercut" salience 9999 // should have max priority when $m : Match( $handles : factHandles ) $v : Match( rule.name == $m.Undercuts, factHandles == $handles ) then System.out.println( "Activation of rule " + $m.getRule().getName() + " overrides " + $v.getRule().getName() + " for tuple " + $handles ); kcontext.cancelMatch( $v ); end {code} Let me know if this would be enough for your concrete use case. Davide > Rule attribute for adding inverse of consequence as rule condition > ------------------------------------------------------------------ > > Key: DROOLS-365 > URL: https://issues.jboss.org/browse/DROOLS-365 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 5.5.0.Final > Reporter: Adar Dembo > Assignee: Mark Proctor > > I have quite a few rules that look like this: > {noformat} > rule "if foo then bar" > when > Foo($a : a, $b : b) > not Bar(a == $a, b == $b) > then > insert(new Bar($a, $b)); > end > {noformat} > This is a fairly common pattern for me: a rule should not activate if the facts generated by its consequence were already asserted. It's a pattern I use extensively to generate linear (i.e. non-repeating) workflows. > Ideally I'd be able to express it as follows: > {noformat} > rule "if foo then bar" > condition-on-inverse-of-consequence > when > Foo($a : a, $b : b) > then > insert(new Bar($a, $b)); > end > {noformat} > And {{condition-on-inverse-of-consequence}} would cause Drools to generate the right kind of condition, which would be the inverse of the fact changes made by the consequence. > I think {{lock-on-active}} is similar but harsher: it prevents the rule from firing a second time altogether, regardless of input. At least, that's based on my reading of the docs. In my example, that would be equivalent to {{not Bar()}} condition in the rule, which is stricter than {{not Bar(a == $a, b == $b)}}. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-95) Add Logger/LoggerProvider to support new Log4j 2 to improve performance

by Nicholas Williams (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-95?page=com.atlassian.jira.plug... ] Nicholas Williams commented on JBLOGGING-95: -------------------------------------------- Can we please get this merged and backported to 3.1, and release 3.1.4.GA? > Add Logger/LoggerProvider to support new Log4j 2 to improve performance > ----------------------------------------------------------------------- > > Key: JBLOGGING-95 > URL: https://issues.jboss.org/browse/JBLOGGING-95 > Project: JBoss Logging > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: jboss-logging-spi > Affects Versions: 3.2.0.Beta1 > Reporter: Nicholas Williams > Assignee: David Lloyd > Priority: Minor > Fix For: 3.2.0.Beta1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > The new Log4j 2 project will be released soon. It has major improvements over Log4j and Logback. Currently, JBoss Logging can log to Log4j 2 indirectly by way of SLF4J (if the log4j-slf4j artifact is on the classpath) or the Log4j 1.2 API (if the log4j-1.2-api artifact is on the classpath and when JBLOGGING-94 is fixed). However, performance would be improved if JBoss Logging could log directly to the Log4j 2 API. > Looks like we just need a new {{Log4j2Logger}} and {{Log4j2LoggerProvider}}. I'll try to submit a pull request in the next few weeks. I'm currently working on other tasks in Log4j 2. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2621) Distributable @StatefulTimeout(0L) EJBs should not be immortal

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-2621?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-2621: ------------------------------- Summary: Distributable @StatefulTimeout(0L) EJBs should not be immortal (was: Zero Timeout Stateful EJB Leak (clustered)) > Distributable @StatefulTimeout(0L) EJBs should not be immortal > -------------------------------------------------------------- > > Key: WFLY-2621 > URL: https://issues.jboss.org/browse/WFLY-2621 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 8.0.0.CR1 > > > Stateful EJB instances are not removed from cache upon release, if the timeout is zero. > Apply WFLY-2590 fix to distributable cache. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2622) Use expiration thread pool per deployment instead of per bean

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-2622: ---------------------------------- Summary: Use expiration thread pool per deployment instead of per bean Key: WFLY-2622 URL: https://issues.jboss.org/browse/WFLY-2622 Project: WildFly Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 8.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 8.0.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2616) SEVERE is not an available logging level in the CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2616?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2616: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1038862|https://bugzilla.redhat.com/show_bug.cgi?id=1038862] from ASSIGNED to POST > SEVERE is not an available logging level in the CLI > --------------------------------------------------- > > Key: WFLY-2616 > URL: https://issues.jboss.org/browse/WFLY-2616 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > Fix For: 8.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2616) SEVERE is not an available logging level in the CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2616?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2616: ----------------------------------------------- James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1038862|https://bugzilla.redhat.com/show_bug.cgi?id=1038862] from NEW to ASSIGNED > SEVERE is not an available logging level in the CLI > --------------------------------------------------- > > Key: WFLY-2616 > URL: https://issues.jboss.org/browse/WFLY-2616 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > Fix For: 8.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2616) SEVERE is not an available logging level in the CLI

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2616?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-2616: -------------------------------- Component/s: Logging > SEVERE is not an available logging level in the CLI > --------------------------------------------------- > > Key: WFLY-2616 > URL: https://issues.jboss.org/browse/WFLY-2616 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2616) SEVERE is not an available logging level in the CLI

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-2616?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-2616: -------------------------------- Fix Version/s: 8.0.0.CR1 > SEVERE is not an available logging level in the CLI > --------------------------------------------------- > > Key: WFLY-2616 > URL: https://issues.jboss.org/browse/WFLY-2616 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Logging > Reporter: Kyle Lape > Assignee: James Perkins > Fix For: 8.0.0.CR1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2013