[JBoss JIRA] Created: (JBRULES-2673) There Should be a Relation Between the Fired Rule and the Node which Activates the Ruleflow-Group
by Anatoly Polinsky (JIRA)
There Should be a Relation Between the Fired Rule and the Node which Activates the Ruleflow-Group
-------------------------------------------------------------------------------------------------
Key: JBRULES-2673
URL: https://jira.jboss.org/browse/JBRULES-2673
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Environment: N/A
Reporter: Anatoly Polinsky
Assignee: Mark Proctor
We asked for the following behavior to be implemented:
@Test(expected=NameOfOurLayerOtTopOfDroolsException.class)
public void shouldThrowNameOfOurLayerOtTopOfDroolsExceptionForAnyThrowableThrownWithinDroolsOnTheProcessStart() {
ksession.startProcess("com.jpmc...process-throws-throwable");
}
@Test(expected=NameOfOurLayerOtTopOfDroolsException.class)
public void shouldThrowNameOfOurLayerOtTopOfDroolsExceptionForAnyThrowableThrownWithinDroolsOnTheProcessResume() {
ksession.getWorkItemManager().completeWorkItem( id, null );
}
And Plugtree was prompt to create it for us: http://anonsvn.jboss.org/repos/labs/labs/jbossrules/branches/5_1_20100802...
The only roadblock here, to fulfill our original request, is when Throwable is thrown from within a "ruleflow-group" ( from within rules that are embedded into / invoked from a workflow ), in which case Throwable cannot be caught by the above mechanism due to the fact that:
"At the moment Drools doesn't keep any relation between the fired rule and the node which activates the ruleflow-group, thus if an activated rule blows up there is no way to know which node has made focus on its group"
Since Drools is moving towards having everything under "a single roof/parent of Knowledge", Process and Rule children should be rather siblings than strangers, hence should know a little more about each other.
/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
13 years, 9 months
[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
13 years, 9 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
13 years, 9 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
13 years, 9 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
13 years, 9 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
13 years, 9 months
[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
13 years, 9 months
[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
13 years, 9 months