[rules-users] NPE in FireAllRulesCommand (bug?)

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