[rules-dev] Failure updating working memory - trying to convert a String to a long

Edson Tirelli tirelli at post.com
Mon Jan 21 16:28:37 EST 2008


    This exception is raised when there is a rule with a constraint that
tries to compare values of different types. The rule you show in your
message may be the rule that triggers the problem, because of the update,
but certainly it is not the rule that contains the problem.
    You need to look for a rule in your rulebase that is comparing (I guess)
the source attribute of your sensor to an integer/long value.

    Maybe we should add support for String to Number conversion on Object
attributes or support a specific extractor for String attributes. Right now,
the code looks like:

    public long getLongValue(InternalWorkingMemory workingMemory, final
Object object) {
        final Object value = getValue( workingMemory, object );
        if ( value instanceof Number ) {
            return ((Number) value).longValue();
        }
        throw new RuntimeDroolsException( "Conversion to long not supported
from " + value.getClass().getName() );
    }

   If you can provide a self contained test showing your use case and open a
JIRA with it, I will take a look.

   []s
   Edson

2008/1/21, Warren, David [USA] <warren_david at bah.com>:
>
>   I am trying to get a project that runs in Drools 3 working on Drools 4.
> Several of the rules in our DRL file are failing for the same reason,
> which is described below.  I have searched for documentation where someone
> encountered this error, but have found none, which is why I am writing the
> list.
>
> Here is a sample rule that fails:
>
> rule 'X'
> salience 750
> when
> s : Sensor( source == "Not in File" , TCN matches "CRM[0-9]+MXFS[0-9]+" )
> then
> System.out.println("Rule executed: X " );
> s.setSource("X");
> System.out.println( "in rule location 2");
> update(s);
> System.out.println( "in rule location 3");
> end
>
> The rule fails  when  the "update(s);" statement  is executed, with the
> error that a String cannot be converted to a long (stack trace is below).
> The Sensor class has several variables.  The last getter method called
> before the failure returns a long.  The source variable (which is set in
> the RHS of the rule) is a String , and the for source is the 2nd to last
> getter called.
>
> Does anyone have an idea why this update statement would fail - why it
> would be trying to convert a String to a long?
>
> Thank you,
> David Warren
>
> Stack trace:
>
> org.drools.RuntimeDroolsException: Conversion to long not supported from
> java.lang.String
> at org.drools.base.extractors.BaseObjectClassFieldExtractor.getLongValue(
> BaseObjectClassFieldExtractor.java:106)
> at org.drools.base.ClassFieldExtractor.getLongValue(
> ClassFieldExtractor.java:203)
> at
> org.drools.rule.VariableRestriction$LongVariableContextEntry.updateFromTuple
> (VariableRestriction.java:284)
> at org.drools.common.SingleBetaConstraints.updateFromTuple(
> SingleBetaConstraints.java:100)
> at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:102)
> at
> org.drools.reteoo.CompositeTupleSinkAdapter.createAndPropagateAssertTuple(
> CompositeTupleSinkAdapter.java:73)
> at org.drools.reteoo.LeftInputAdapterNode.assertObject(
> LeftInputAdapterNode.java:116)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(
> CompositeObjectSinkAdapter.java:318)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:140)
> at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(
> CompositeObjectSinkAdapter.java:299)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:153)
> at org.drools.reteoo.Rete.assertObject(Rete.java:175)
> at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192)
> at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java
> :71)
> at org.drools.common.AbstractWorkingMemory.insert(
> AbstractWorkingMemory.java:909)
> at org.drools.common.AbstractWorkingMemory.insert(
> AbstractWorkingMemory.java:881)
> at org.drools.base.DefaultKnowledgeHelper.insert(
> DefaultKnowledgeHelper.java:67)
> at org.drools.base.DefaultKnowledgeHelper.insert(
> DefaultKnowledgeHelper.java:61)
> at com.bah.aims.rules.Rule_X_0.consequence(Rule_X_0.java:32)
> at com.bah.aims.rules.Rule_X_0ConsequenceInvoker.evaluate
> (Rule_X_0ConsequenceInvoker.java:22)
> at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550)
> at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(
> AbstractWorkingMemory.java:471)
> at org.drools.common.AbstractWorkingMemory.fireAllRules(
> AbstractWorkingMemory.java:433)
> at com.bah.aims.rules.compiler.SensorPairRulesTest.testNotInFileIqcrm(
> SensorPairRulesTest.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> ...
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>


-- 
  Edson Tirelli
  JBoss Drools Core Development
  Office: +55 11 3529-6000
  Mobile: +55 11 9287-5646
  JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20080121/ab54b801/attachment.html 


More information about the rules-dev mailing list