[JBoss JIRA] Created: (JBRULES-2650) Stable API should provide Agenda.getActivations()
by Wolfgang Laun (JIRA)
Stable API should provide Agenda.getActivations()
-------------------------------------------------
Key: JBRULES-2650
URL: https://jira.jboss.org/browse/JBRULES-2650
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.1.1.FINAL
The stable API lets you retrieve Agenda from WorkingMemory, and there is an IF for Activation. There should be a
List<Activation> getActivations
in the "stable" Agenda.
This would be highly useful for writing supportive code for inspecting the engine's state at critical points. (I don't see that restricting Agenda views to specific "groups" would be a benefit for such tasks.)
--
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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months
[JBoss JIRA] Created: (JBRULES-2735) ClassCastException for casting DefaultFactHandle to EventFactHandle when using Sliding Windows
by Will Lauer (JIRA)
ClassCastException for casting DefaultFactHandle to EventFactHandle when using Sliding Windows
----------------------------------------------------------------------------------------------
Key: JBRULES-2735
URL: https://jira.jboss.org/browse/JBRULES-2735
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.1.1.FINAL
Environment: Windows XP SP3, Java 1.6.0_21, Drools 5.1.1
Reporter: Will Lauer
Assignee: Mark Proctor
When playing with a simple sliding window test using a single type of fact with @role(event), the following ClassCastException is generated:
Exception in thread "main" java.lang.ClassCastException: org.drools.common.DefaultFactHandle cannot be cast to org.drools.common.EventFactHandle
at org.drools.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.evaluateCachedLeft(BeforeEvaluatorDefinition.java:333)
at org.drools.rule.VariableRestriction.isAllowedCachedLeft(VariableRestriction.java:110)
at org.drools.rule.VariableConstraint.isAllowedCachedLeft(VariableConstraint.java:115)
at org.drools.common.SingleBetaConstraints.isAllowedCachedLeft(SingleBetaConstraints.java:142)
at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:274)
at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:138)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:189)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:64)
at org.drools.reteoo.AccumulateNode.evaluateResultConstraints(AccumulateNode.java:662)
at org.drools.reteoo.AccumulateNode.assertLeftTuple(AccumulateNode.java:181)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:189)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:138)
at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:148)
at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:450)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:368)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:190)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:145)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1174)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1123)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:917)
at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:251)
at net.wlauer.DroolsEngine.NonSpringRulesEngine.main(NonSpringRulesEngine.java:71)
--
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
12 years, 4 months
[JBoss JIRA] Created: (JBRULES-2751) NullPointerException in DeclarationTypeFixer: An rule compilation error should give a clear errow warning with an indecation of which rule is the culprit instead of a NPE
by Geoffrey De Smet (JIRA)
NullPointerException in DeclarationTypeFixer: An rule compilation error should give a clear errow warning with an indecation of which rule is the culprit instead of a NPE
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-2751
URL: https://jira.jboss.org/browse/JBRULES-2751
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Affects Versions: 5.1.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Edson Tirelli
Fix For: 5.2.0.M1
{code}
Exception in thread "main" java.lang.NullPointerException
at org.drools.rule.builder.dialect.java.DeclarationTypeFixer.fix(DeclarationTypeFixer.java:17)
at org.drools.rule.builder.dialect.java.AbstractJavaRuleBuilder.createVariableContext(AbstractJavaRuleBuilder.java:90)
at org.drools.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:112)
at org.drools.rule.builder.dialect.java.JavaAccumulateBuilder.build(JavaAccumulateBuilder.java:54)
at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:223)
at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:108)
at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69)
at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:79)
at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1149)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:631)
at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:270)
at org.drools.planner.config.localsearch.LocalSearchSolverConfig.buildRuleBase(LocalSearchSolverConfig.java:209)
at org.drools.planner.config.localsearch.LocalSearchSolverConfig.buildSolver(LocalSearchSolverConfig.java:186)
at org.drools.planner.config.XmlSolverConfigurer.buildSolver(XmlSolverConfigurer.java:93)
at org.drools.planner.examples.cloudbalancing.app.CloudBalancingApp.createSolver(CloudBalancingApp.java:43)
at org.drools.planner.examples.common.app.CommonApp.createSolutionBusiness(CommonApp.java:59)
at org.drools.planner.examples.common.app.CommonApp.<init>(CommonApp.java:38)
at org.drools.planner.examples.cloudbalancing.app.CloudBalancingApp.<init>(CloudBalancingApp.java:30)
at org.drools.planner.examples.cloudbalancing.app.CloudBalancingApp.main(CloudBalancingApp.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:115)
{code}
Here's the rule which causes this:
{code}
rule "minimalCpuPowerTotal"
when
$cloudComputer : CloudComputer($cpuPower : cpuPower)
$minimalCpuPowerTotal : Number(intValue > $cpuPower) from accumulate(
CloudAssignment(
cloudComputer == $cloudComputer,
$minimalCpuPower : minimalCpuPower), // This is the problem, CloudAssignment.getMinimalCpuPower does not exist yet
sum($minimalCpuPower)
)
then
insertLogical(new IntConstraintOccurrence("minimalCpuPowerTotal", ConstraintType.NEGATIVE_HARD,
$minimalCpuPowerTotal - $cpuPower,
$cloudComputer));
end
{code}
CloudAssignment did not have a getter for minimalCpuPower yet.
The compilation error should clearly say that its the rule minimalCpuPowerTotal which has a problem and that the getter for the field minimalCpuPower wasn't found.
--
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
12 years, 4 months
[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
12 years, 4 months
[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
12 years, 4 months