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

Mike Melton mike.melton at gmail.com
Tue Mar 13 12:34:25 EDT 2012


JBRULES-3421 created and pull request submitted with fix and tests.


On Fri, Mar 2, 2012 at 1:57 PM, Mike Melton <mike.melton at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20120313/befa5464/attachment.html 


More information about the rules-users mailing list