[rules-users] JBRULES-3260: Events forced to zero expirationOffset

[Edson Tirelli]

   Hi Robert,

   Good catch. I fixed this and will commit it in a few minutes. It will be
included in the next release. You will be able to download fixed binaries
from hudson or you can build them yourself.

   Edson

2011/10/22 Robert Crawford <crawford at kloognome.com>

> It seems like ever since I found this, I can't stop tripping this
> condition.
>
> Basically, while adding the DRL files to the KnowledgeBuilder,
> ReteooRuleBase decides it has to reconcile event definitions from different
> "packages", so it looks for any that are assignable. At first I thought
> this
> was just a guard against having a parent expire quicker than a child class
> and breaking rules for the child. But now I'm getting this condition for A
> SINGLE CLASS WITH NO INHERITANCE.
>
> At the root of the problem is ReteooRuleBase line 477:
> node.setExpirationOffset( Math.max( node.getExpirationOffset(),
> typeDeclaration.getExpirationOffset()+1 ) );
>
> Since neither node nor typeDeclaration have declared expirations, they both
> have expirationOffset values of -1. The code evaluates:
>
> max(-1, -1 + 1)
>
> sets the expirationOffset for node to zero, and from then on my objects are
> expired literally as I insert them.
>
> If someone could more clearly state the conditions that trip this code, I'd
> do my best to avoid them. I've already eliminated inheritance among my
> events, but that doesn't seem to be enough.
>
>
>
> --
> View this message in context:
> http://drools.46999.n3.nabble.com/JBRULES-3260-Events-forced-to-zero-expirationOffset-tp3444069p3444069.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20111022/7b254055/attachment.html