[rules-users] npe in LogicalRetractCallback when using jpa persistence

Chris Raschl c.raschl at dyless.com
Tue Aug 10 04:09:06 EDT 2010


Hi,
Just in case someone faces the same problem, comments inline:

Am 05.08.2010 13:53, schrieb Chris Raschl:
> I'm using the latest drools and drools flow snapshot with jpa persistence.
>
> When I'm retracting a fact from the knowledge session (which causes
> logical retraction), the session can't be persisted any more.
>
> During retraction a LogicalRetractCallback is instantiated using this
> constructor:
>
> public LogicalRetractCallback(final TruthMaintenanceSystem tms,
>                                 final LogicalDependency node,
>                                 final Set set,
>                                 final InternalFactHandle handle,
>                                 final PropagationContext context,
>                                 final Activation activation) {
>       this.tms = tms;
>       this.node = node;
>       this.set = set;
>       this.handle = handle;
>       this.context = context;
> }
>
> As you can see an activation object can be passed (and actually is
> passed) to the constructor, but is never used. Retraction works though.
>
> The problem occurs when the knowledge session is persisted, because
> LogicalRetractCallback.write assumes that activation is not null, which
> leads to this npe:
>
> Caused by: java.lang.NullPointerException
> org.drools.common.TruthMaintenanceSystem$LogicalRetractCallback.write(TruthMaintenanceSystem.java:251)
> org.drools.marshalling.impl.OutputMarshaller.writeActionQueue(OutputMarshaller.java:201)

Adding this.activation = activation to the constructor does not help,
beause the npe in the write method remains. I tried it, then the whole 
expression "context.terminalTupleMap.get( this.activation.getTuple() )" 
in the write method evaluates to null...

I found out persistence was triggered by an unneccessary flush in my 
code. I removed that, everything works now.

That seems to be the case because the action queue is empty then and 
there's no need to persist it, thus the write method is never called. I 
guess the problem remains if someone tries to persist a session with an 
action queue containing a LogicalRetractCallback object.

- chris



More information about the rules-users mailing list