September 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2691) Accumulated Code Clean-Up Issues

by Wolfgang Laun (JIRA)

Accumulated Code Clean-Up Issues -------------------------------- Key: JBRULES-2691 URL: https://jira.jboss.org/browse/JBRULES-2691 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Reporter: Wolfgang Laun Assignee: Mark Proctor This issue is meant to be a portmanteau for all relics resulting from refactorings, modifactions, additions and deletions - in short, the flotsam and jetsam of ongoing software maintenance. (.) There are two eponymous classes: org.drools.base.DefaultConsequenceExceptionHandler org.drools.runtime.rule.impl.DefaultConsequenceExceptionHandler and, thrown from these: org.drools.spi.ConsequenceException org.drools.runtime.rule.ConsequenceException Mark: "I believe it's historical,... drools-api has been there long enough that we can start to clean all this up now." (.) Problem reported with ksession.fireAllRules(new RuleNameEndsWithAgendaFilter("test")); Thomas Swindells: Looks like [...] that there are two agenda filter classes: org.drools.runtime.rule.AgendaFilter and org.drools.spi.AgendaFilter. The first one, odrr.AgendaFilter is what is required by the StatefulKnowledgeSession, this then wraps it in a class to convert it to an ods.AgendaFilter which is what the internal classes use. RuleNameEndsWithAgendaFilter seems to implement ods.AgendaFilter and not odrr.AgendaFilter which is what I'd expect - this is possibly a bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

6
13
0 / 0

[JBoss JIRA] Created: (JBRULES-2554) Adding a StatefulKnowledgeSessionAware Interface

by Anatoly Polinsky (JIRA)

Adding a StatefulKnowledgeSessionAware Interface ------------------------------------------------ Key: JBRULES-2554 URL: https://jira.jboss.org/browse/JBRULES-2554 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-api Affects Versions: 5.1.0.M2 Environment: N/A Reporter: Anatoly Polinsky Assignee: Mark Proctor Priority: Minor Interface to be implemented by any object that wishes to be notified of the {@link org.drools.runtime.StatefulKnowledgeSession} that it runs in. Implementing this interface makes sense for example when an object requires access to session artifacts/details such as rule facts, sessionID, etc. This interface can be implemented by a custom {@link org.drools.process.instance.WorkItemHandler} in case, for example, it needs to access a session to insert / retract some facts before proceeding further to the process node that fires rules ( groups, agendas, etc.. ). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

6
12
0 / 0

[JBoss JIRA] Created: (JBRULES-2621) NPE due to activation.getDeclarationValue( declId )

by Wolfgang Laun (JIRA)

NPE due to activation.getDeclarationValue( declId ) --------------------------------------------------- Key: JBRULES-2621 URL: https://jira.jboss.org/browse/JBRULES-2621 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-api Affects Versions: 5.1.0.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.1.1.FINAL Trying to access the declarations and their values of an activation, as used during ActivationEvent logging: List<String> declIds = ); for( String declId: activation.getDeclarationIDs( ){ Object declVal = activation.getDeclarationValue( declId ); // ... } If, however, a fact is retracted, this code, when executed for an AfterActivationFiredEvent, throws a NPE when declId is a binding for a component of the retracted fact. The optimum solution would be to not get such useless bindings in the List<String> returned by getDeclarationIDs() which is in AgendaItem.java. I have added the if-statement. The following code is untested: public List<String> getDeclarationIDs() { Declaration[] declArray = this.getRule().getDeclarations(); List<String> declarations = new ArrayList<String>(); for( Declaration decl : declArray ) { // return only "sound" declaration IDs if( this.tuple.get( decl ).getObject() != null ){ declarations.add( decl.getIdentifier() ); } } return Collections.unmodifiableList( declarations ); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

7
13
0 / 0

[JBoss JIRA] Created: (JBRULES-2619) Extend API of IF Rule: no access to interesting attributes

by Wolfgang Laun (JIRA)

Extend API of IF Rule: no access to interesting attributes -------------------------------------------------------------- Key: JBRULES-2619 URL: https://jira.jboss.org/browse/JBRULES-2619 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-api Affects Versions: 5.1.0.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.0.M1 Whereas org.drools.rule.Rule contains a wealth of interesting fields, the stable API org.drools.definition.rule.Rule restricts us to getName() and getPackageName() (and some MetaData). I propose an extension of this interface, providing access to agendaGroup, activationGroup and ruleFlowGroup. I see no obvious reason why these user defined attributes should remain hidden. These rule attributes would provide a good opportunity for writing more sophisticated event loggers, letting you specify rule filters by natural rule groupings. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

7
14
0 / 0

[JBoss JIRA] Created: (JBRULES-2620) ActivationCreatedEvent - Activation: InitialFactImpl in Object set

by Wolfgang Laun (JIRA)

ActivationCreatedEvent - Activation: InitialFactImpl in Object set ---------------------------------------------------------------------- Key: JBRULES-2620 URL: https://jira.jboss.org/browse/JBRULES-2620 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-api Affects Versions: 5.1.0.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.1.1.FINAL Given this rule rule "show no gaps" when not Gap() then System.out.println( "No gaps!" ); end the ActivationCreatedEvent references an Activation, where the list of fact handles (getFactHandles) contains one element, but its Object is null: Fact null @0:0:27032609:1306428912:0:DEFAULT But the list of objects (getObjects) returns a list where there *is* an object: Object (org.drools.reteoo.InitialFactImpl): org.drools.reteoo.InitialFactImpl@4dde85f0 This should be changed; neither a fact handle nor an object should be returned if there are no user objects participating in the activation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

7
14
0 / 0

[JBoss JIRA] Created: (JBRULES-2696) KnowledgeBaseDefinitionParser Should Always Create KnowledgeBaseOptionsConfiguration

by Anatoly Polinsky (JIRA)

KnowledgeBaseDefinitionParser Should Always Create KnowledgeBaseOptionsConfiguration ------------------------------------------------------------------------------------ Key: JBRULES-2696 URL: https://jira.jboss.org/browse/JBRULES-2696 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.1.FINAL Environment: N/A Reporter: Anatoly Polinsky Assignee: Mark Proctor KnowledgeBaseOptionsConfiguration: * <p> * This class will automatically load default values from a number of places, accumulating properties from each location. * This list of locations, in given priority is: * System properties, home directory, working directory, META-INF/ of optionally provided classLoader * META-INF/ of Thread.currentThread().getContextClassLoader() and META-INF/ of ClassLoader.getSystemClassLoader() * </p> Since this properties are only read when "RuleBaseConfiguration" ( KnowledgeBaseOptionsConfiguration implementor ) is constructed, this does not apply/work in case KnowledgeBase is defined via Spring without a <drools:configuration> due to the current sequence of events in "KnowledgeBaseDefinitionParser": Element kbaseConf = DomUtils.getChildElementByTagName(element, "configuration"); if ( kbaseConf != null ) { BeanDefinitionBuilder rbaseConfBuilder = BeanDefinitionBuilder.rootBeanDefinition( RuleBaseConfiguration.class ); // ... ... ... factory.addPropertyValue( "conf", rbaseConfBuilder.getBeanDefinition() ); } To fix it, RuleBaseConfiguration ( which implements KnowledgeBaseOptionsConfiguration ) should be created even though "<drools:configuration>" was not provided ( kbaseConf == null ): Element kbaseConf = DomUtils.getChildElementByTagName(element, "configuration"); BeanDefinitionBuilder rbaseConfBuilder = BeanDefinitionBuilder.rootBeanDefinition( RuleBaseConfiguration.class ); if ( kbaseConf != null ) { // ... ... ... } factory.addPropertyValue( "conf", rbaseConfBuilder.getBeanDefinition() ); Thank you, /Anatoly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

6
12
0 / 0

[JBoss JIRA] Created: (JBRULES-2695) Spring "Drools Resources" Need to be Modular

by Anatoly Polinsky (JIRA)

Spring "Drools Resources" Need to be Modular -------------------------------------------- Key: JBRULES-2695 URL: https://jira.jboss.org/browse/JBRULES-2695 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.1.FINAL Environment: N/A Reporter: Anatoly Polinsky Assignee: Mark Proctor When development is done by multiple teams, there should be a way to reference the resources in a modular way. Here is how it is / can be done now ( which is BAD / not modular ): <drools:kbase id="kbase"> <drools:resources> <drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_1.drf"/> <drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_2.drf"/> <drools:resource type="DRF" source="classpath:org/drools/container/spring/team2_1.drf"/> <drools:resource type="DRF" source="classpath:org/drools/container/spring/team2_2.drf"/> <drools:resource ref="team3_1"/> <drools:resource ref="team3_2"/> </drools:resources> </drools:kbase> Since clients need to be aware of _every_ little artifact of individual team, and have to reimport all artifacts into a knowledge base one by one. Here is a better way to do it: <drools:kbase id="kbase"> <drools:resources ref="team1-resources"/> <drools:resources ref="team2-resources"/> <drools:resources ref="team3-resources"/> </drools:kbase> where individual team's config may look as: (e.g. team 1): <drools:resources id="team1-resources"> <drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_1.drf"/> <drools:resource type="DRF" source="classpath:org/drools/container/spring/team1_2.drf"/> </drools:resources/> ------------------------------------------------------------------------------ Long story short: "drools:resources" needs: 1. ID, to be able to ref to it 2. REF, to be able to ref to an ID "drools:kbase" needs: 1. To optionally take a list of "drools:resources" Thank you, /Anatoly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

7
13
0 / 0

[JBoss JIRA] Created: (JBRULES-2616) Process persistent timers

by Diego Lopez Leon (JIRA)

Process persistent timers ------------------------- Key: JBRULES-2616 URL: https://jira.jboss.org/browse/JBRULES-2616 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-process Affects Versions: 5.1.0.FINAL Reporter: Diego Lopez Leon Assignee: Mark Proctor Implement a mechanism to allow scheduled timers to be triggered beyond the scope of a disposed session. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-1052) Ergonomics

by Bela Ban (JIRA)

Ergonomics ---------- Key: JGRP-1052 URL: https://jira.jboss.org/jira/browse/JGRP-1052 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 The goal is to (a) reduce the number of properties needed and (b) determine the values dynamically. Examples: - Determine the best min/max size of a thread pool - Find out what the best timeout values are for retransmission, e.g. based on average retransmission times - Determine the optimal number of credits in FC This is similar to the JVM setting where, starting with 1.5, the initial values can be set, but over time, the JVM dynamically changes them. In the best case, a config contains only a list of protocols without any properties, and JGroups will figure out the correct values. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2438) loading multiple sheets of single Excel book by one change-set xml

by Toshiya Kobayashi (JIRA)

loading multiple sheets of single Excel book by one change-set xml ------------------------------------------------------------------ Key: JBRULES-2438 URL: https://jira.jboss.org/jira/browse/JBRULES-2438 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Reporter: Toshiya Kobayashi Assignee: Mark Proctor I'm trying to use rules via DecisionTable using change-set. I wrote rules in multiple sheets of single Excel book. Then I configured my change-set xml like: ... <add> <resource source='classpath:data/dtable.xls' type="DTABLE"> <decisiontable-conf input-type="XLS" worksheet-name="sheet1" /> </resource> <resource source='classpath:data/dtable.xls' type="DTABLE"> <decisiontable-conf input-type="XLS" worksheet-name="sheet2" /> </resource> </add> ... But only rules of sheet1 were loaded. As far as I observed source codes, KnowledgeAgentImpl.java puts resource into "Map<Resource, ResourceMapping> resources". But even if multiple resources are configured in change-set, it appears to me like those resources are considered as the same resource and eventually only one resource will be registered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

4
22
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2010