April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-116) Import PMML files as resources

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-116?page=com.atlassian.jira.plugin... ] Davide Sottara moved JBRULES-2948 to DROOLS-116: ------------------------------------------------ Project: Drools (was: JBRULES) Key: DROOLS-116 (was: JBRULES-2948) Workflow: GIT Pull Request workflow (was: jira) > Import PMML files as resources > ------------------------------ > > Key: DROOLS-116 > URL: https://issues.jboss.org/browse/DROOLS-116 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Mark Proctor > Priority: Minor > > Predictive models should be embedded and evaluated in a Drools session > Models encoded in PMML (Predictive Model Markup Language) should be imported > and translated in rules. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-117) The "from" CE does not manage @events correctly

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-117?page=com.atlassian.jira.plugin... ] Davide Sottara moved JBRULES-3637 to DROOLS-117: ------------------------------------------------ Project: Drools (was: JBRULES) Key: DROOLS-117 (was: JBRULES-3637) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: (was: 5.4.0.Final) Component/s: (was: drools-core (fusion)) Fix Version/s: (was: 6.0.0.Alpha1) > The "from" CE does not manage @events correctly > ----------------------------------------------- > > Key: DROOLS-117 > URL: https://issues.jboss.org/browse/DROOLS-117 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Edson Tirelli > Priority: Critical > > If an event type (i.e. an instance of a class marked with @role(event)) is returned by a "from" node, it is not wrapped by an EventFactHandle as expected, so e.g. any attempt to use temporal operators will fail. > See the test case below for an example > The problem is in FromNode.java around line 200, where the new handles are created without passing an ObjectTypeConfiguration, leading to the default creation of a DefaultFactHandle. > I wonder if it's possible to simply retrieve the ObjectTypeConf: > workingMemory.getObjectTypeConfigurationRegistry().getObjectTypeConf( context.getEntryPoint(), object ) > and pass it to the handle factory method. > I tested it and it works for the test case below, but there may be other > side-effects I'm not seeing. > --------------------------------------------------------------------------- > May be related (but not the same as) #JBRULES-2423 -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-118) Parser fails to read files ending with a comment

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-118?page=com.atlassian.jira.plugin... ] Davide Sottara moved JBRULES-3185 to DROOLS-118: ------------------------------------------------ Project: Drools (was: JBRULES) Key: DROOLS-118 (was: JBRULES-3185) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: (was: 5.3.0.Beta1) Component/s: (was: drools-compiler) > Parser fails to read files ending with a comment > ------------------------------------------------ > > Key: DROOLS-118 > URL: https://issues.jboss.org/browse/DROOLS-118 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Edson Tirelli > Priority: Minor > > When the last line of a DRL file is a comment, parser fails with "no viable alternative at input ''" -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-115) Add support for strong negation

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-115?page=com.atlassian.jira.plugin... ] Mark Proctor moved JBRULES-3626 to DROOLS-115: ---------------------------------------------- Project: Drools (was: JBRULES) Key: DROOLS-115 (was: JBRULES-3626) Workflow: GIT Pull Request workflow (was: jira) Fix Version/s: 6.0.0.CR1 (was: 6.0.0.Alpha1) > Add support for strong negation > ------------------------------- > > Key: DROOLS-115 > URL: https://issues.jboss.org/browse/DROOLS-115 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 6.0.0.CR1 > > > Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...". > However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..." > It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT. > The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as: > when $p : Person() and Car( owner == $p ) then > // a positive, matching Car is present in the WM > when $p : Person() and neg Car( owner == $p ) then > // a negative, matching Car is present in the WM > when $p : Person() and not Car( owner == $p ) then > // neither a positive nor a negative fact exists in the WM > For a more detailed description and motivation see e.g.: > https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-113) Certainty Factors

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-113?page=com.atlassian.jira.plugin... ] Mark Proctor moved JBRULES-359 to DROOLS-113: --------------------------------------------- Project: Drools (was: JBRULES) Key: DROOLS-113 (was: JBRULES-359) Workflow: GIT Pull Request workflow (was: jira) Component/s: (was: All) > Certainty Factors > ----------------- > > Key: DROOLS-113 > URL: https://issues.jboss.org/browse/DROOLS-113 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assignee: Davide Sottara > > We need a generic solution that allows Drools to support all the various forms to handle certainty: > Bayesian > Fuzzy > Argumentation > etc > A wiki page has been made to hash out the spec/design details: > http://wiki.jboss.org/wiki/Wiki.jsp?page=CertaintyFactors -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-114) Support "Defeasible" rules in Drools

by Mark Proctor (JIRA)

[ https://issues.jboss.org/browse/DROOLS-114?page=com.atlassian.jira.plugin... ] Mark Proctor moved JBRULES-3613 to DROOLS-114: ---------------------------------------------- Project: Drools (was: JBRULES) Key: DROOLS-114 (was: JBRULES-3613) Workflow: GIT Pull Request workflow (was: jira) Component/s: (was: drools-core) (was: drools-compiler) > Support "Defeasible" rules in Drools > ------------------------------------ > > Key: DROOLS-114 > URL: https://issues.jboss.org/browse/DROOLS-114 > Project: Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Critical > > Very roughly speaking, "defeasiblity" is about rules being able to prevent other rules from firing, or canceling the conclusions other rules. > It is used to manage "exceptions" or "(counter)arguments", where different rules lead to conflicting conclusions and a resolution strategy has to be applied, depending on some relative ordering (strength, salience, temporal, weight, etc..). > While an ad-hoc implementation is possible combining salience, appropriate insertions/retractions and the rule-based agenda, a more declarative approach should be provided to the user. > This lack of a feature is currently a blocker for the adoption of Drools in several medical and legal communities, just to cite some. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-732) Ability to declare a dependency on a service name

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-732?page=com.atlassian.jira.plugin.s... ] Stuart Douglas commented on WFLY-732: ------------------------------------- I think that the combination of inter deployment dependencies and @DependsOn is enough to satisfy all use cases that were discussed. Service names are non-portable and subject to change, so I don't really want to implement this directly unless there is no better solution. > Ability to declare a dependency on a service name > ------------------------------------------------- > > Key: WFLY-732 > URL: https://issues.jboss.org/browse/WFLY-732 > Project: WildFly > Issue Type: Feature Request > Reporter: Brad Maxwell > Assignee: Stuart Douglas > Fix For: Awaiting Volunteers > > > We have several use cases where we need dependencies between different deployments. > Such as > Singleton in ear1 which injects an ejb from ear2 using @EJB. At shutdown we need the Singleton to call a method to clean up on the ejb, however the ejb is sometimes shutdown before the Singleton. Using @DependsOn would allow the Singleton to depend on the EJB if the EJB is in the same ear as the Singleton, however it is not. > There are other use cases where resources are injected and we need the resources to still be deployed at shutdown so we can clean up the resources before they are undeployed. > Having a service name to depend on would be useful and if the name was configurable such that it does not based on the exact name of the deployment, it would be useful as using maven changes the deployment names when we rebuild and we do not want to have to change the code each time we rebuild. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-2423) "from" does not work correctly with events in STREAM mode

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/JBRULES-2423?page=com.atlassian.jira.plug... ] Davide Sottara resolved JBRULES-2423. ------------------------------------- Fix Version/s: 5.5.0.Final (was: 6.0.0.Alpha1) Resolution: Done > "from" does not work correctly with events in STREAM mode > --------------------------------------------------------- > > Key: JBRULES-2423 > URL: https://issues.jboss.org/browse/JBRULES-2423 > Project: JBRULES > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: drools-core (fusion) > Affects Versions: 5.0.0.M1 > Environment: Drools Fusion 5.0+ with engine in STREAM mode > Reporter: Davide Sottara > Assignee: Edson Tirelli > Priority: Critical > Labels: from, fusion, stream > Fix For: 5.5.0.Final > > > In the simple test case below, Message is an instantaneous event (i.e. duration = 0) with a list of destinations. > -------------------------------------------------------------------------------------------------------------------------------------- > declare Message > @role( event ) > @timestamp(start) > @duration(duration) > end > > rule "Hello World" > when > m : Message( status == Message.HELLO, $myMessage : message, $destinations : dest) > $s : String() from $destinations > then > System.out.println( "Dear " + $s + " : >>> " + $myMessage ); > end > -------------------------------------------------------------------------------------------------------------------------------------- > if the engine is configured to work in STREAM mode, the output is > Dear NULL :>>> Hello World > ... > since the Strings extracted from the Collection "dest" have already been retracted by > the time the rule is fired, following the retraction of the Message event. > The problem does not show in CLOUD mode. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3626) Add support for strong negation

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3626?page=com.atlassian.jira.plug... ] Davide Sottara reopened JBRULES-3626: ------------------------------------- Pending re-integration > Add support for strong negation > ------------------------------- > > Key: JBRULES-3626 > URL: https://issues.jboss.org/browse/JBRULES-3626 > Project: JBRULES > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Davide Sottara > Assignee: Davide Sottara > Priority: Minor > Fix For: 6.0.0.Alpha1 > > > Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...". > However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..." > It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT. > The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as: > when $p : Person() and Car( owner == $p ) then > // a positive, matching Car is present in the WM > when $p : Person() and neg Car( owner == $p ) then > // a negative, matching Car is present in the WM > when $p : Person() and not Car( owner == $p ) then > // neither a positive nor a negative fact exists in the WM > For a more detailed description and motivation see e.g.: > https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBRULES-3701) Add ability to trait a map

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/JBRULES-3701?page=com.atlassian.jira.plug... ] Davide Sottara reassigned JBRULES-3701: --------------------------------------- Assignee: Davide Sottara (was: Mark Proctor) > Add ability to trait a map > -------------------------- > > Key: JBRULES-3701 > URL: https://issues.jboss.org/browse/JBRULES-3701 > Project: JBRULES > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: drools-core (expert) > Affects Versions: 5.5.0.Final > Reporter: Ming Fang > Assignee: Davide Sottara > > Add ability to trait a Map as described by Mark Proctor here > http://drools.46999.n3.nabble.com/rules-users-Maps-as-Object-in-Drools-td... > <quote> > //code below is illustrative of what is possible, if changes where mad for above idea. > // Create interface > Person > @Trait > String : name > int : age > end > // Identify the Map instance, and wrap it with the Person interface. > rule > $m : Map[ this['name'] != null, this['age'] != null ) > then > don( $m : Person.class ); > end > // Now the map is identified in a type safe manner. > rule > Person( name == "darth", age == 150 ) > then > …. > end > </quote> -- 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

13 years, 2 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 April 2013