JBRULES-3421 created and pull request submitted with fix and tests.
On Fri, Mar 2, 2012 at 1:57 PM, Mike Melton <mike.melton(a)gmail.com> wrote:
Drools 5.3.1.Final.
I have a use case where I am executing a BatchExecutionCommand against a
stateless session. One of the sub-commands is a FireAllRulesCommand, from
which I would like to retrieve the number of rules actually fired. Since
there is no factory or constructor method to configure both a maximum rules
to fire and an out identifier, I have to use code like this to set up
my FireAllRulesCommand:
FireAllRulesCommand farc = (FireAllRulesCommand)
CommandFactory.newFireAllRules(maxRulesToFire);
farc.setOutIdentifier("num-rules-fired");
commands.add(farc); // commands is List<Command<?>> which I later use to
construct a BatchExecutionCommand
At runtime, when I execute the BatchExecutionCommand, I get an NPE
at FireAllRulesCommand:110. After some investigating, I determined that the
value returned from (ExecutionResultImpl) ((KnowledgeCommandContext)
context).getExecutionResults() is null, which causes the NPE.
As far as I can tell, the cause of this breaks down like so:
- StatelessKnowledgeSession.execute() fires with the batch command as
input.
- It constructs a KnowledgeCommandContext, setting the ExecutionResults
parameter of the constructor to null (line 254).
- KnowledgeCommandContext.executionResults is a private member with no
setter so there is no way to give it a value after it's been instantiated.
- The FireAllRulesCommand fires as part of the batch, and when it tries to
access the execution results from the context, the NPE is thrown.
StatelessKnowledgeSession.execute() later gets the execution results from
the session itself, via the ExecutionResultsImpl instance which is
constructed and passed to the startBatchExecution() method on line 262. I
haven't had time to try this myself, but if we constructed
the ExecutionResultsImpl earlier and passed it to both
the KnowledgeCommandContext constructor and the startBatchExecution()
method, would the problem be alleviated?
In other words, something like this
(StatelessKnowledgeSessionImpl.java:251):
public <T> T execute(Command<T> command) {
StatefulKnowledgeSession ksession = newWorkingMemory();
ExecutionResults results = new ExecutionResultImpl();
KnowledgeCommandContext context = new KnowledgeCommandContext( new
ContextImpl( "ksession",
null ),
null,
null,
ksession,
results
);
try {
((StatefulKnowledgeSessionImpl)
ksession).session.startBatchExecution( results );
If this is indeed a bug and not something silly I'm missing, I'll be happy
to submit a JIRA and even a pull request with the fix.
Thanks
Mike