I thought about asking that yesterday. But thought, no, surely not !

That's OK, mistakes happen !

Good luck.

-----Original Message-----
From: Segal, Jeffrey [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 23 November 2005 12:57 AM
To: [email protected]
Subject: RE: [drools-user] Consequence firing

Just figured it out, and it was indeed right under my nose and a bit
embarrassing.  I was simply not calling workingMemory.fireAllRules() after
asserting my objects, but I was thrown off by the fact that the
isAllowed() methods in my conditions were still being called.  Based on
that, I assumed rule validation was an asynchronous process that began as
soon as objects are asserted into WorkingMemory.

Sorry about that folks...I appreciate the help though!

Jeff

-----Original Message-----
From: Mark Proctor [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 22, 2005 9:44 AM
To: [email protected]
Subject: Re: [drools-user] Consequence firing

Look in the online Semantic Module documentation and read the hello world
example - its not indepth, but should give you the information you need.

Mark
Leotis buchanan wrote:
> How do you register your consequence factory in a conf file , and 
> where will your drools app look for this conf file.
>
> On 11/21/05, Dave B <[EMAIL PROTECTED]> wrote:
>   
>> Have you:
>> - registered your consequence factory in a conf file?
>> - checked that your consequence factory is called?
>> - checked that your consequence factory returns a valid consequence?
>>
>> I vaguely recall having a similar problem a couple of months ago, and

>> indeed remember that the solution was right under my nose -- but I 
>> can't recall the details right now. Will scan my code later today and

>> let you know if that rings any bells.
>>
>> In any case, the debugger is your friend here, should be pretty easy 
>> to track down.
>>
>> Regards,
>> David
>>
>>
>>
>> On 11/22/05, Segal, Jeffrey <[EMAIL PROTECTED]> wrote:
>>     
>>> I've been working on drools DSL for my particular project and have 
>>> overcome all of the classpath, naming convention issues, etc. that 
>>> can come up when using a DSL. The problem I am having is in getting 
>>> my consequences to fire. Here is a sample of how my rules look:
>>>
>>> <rule name="some rule name" salience="50">
>>>
>>> <myNamespace:condition nodeName="node"> <myNamespace:aCondition 
>>> anAttribute="some value"/> <myNamespace:anotherCondition 
>>> anotherAttribute="some other value"> <myNamespace:subelement key="a 
>>> key" value="a value"/> </myNamespace:anotherCondition> 
>>> </myNamespace:condition>
>>>
>>> <myNamespace:consequence nodeName="node"> <myNamespace:myConsequence

>>> anAttribute="a value"> <myNamespace:subelement key="a key" value="a 
>>> value"/> </myNamespace:myConsequence> </myNamespace:consequence>
>>>
>>> </rule>
>>>
>>>
>>> When I assert objects, my conditions are firing as expected and 
>>> without exception. However, I'm not seeing any conditions fire, even

>>> when all of the conditions are true. I.e., isAllowed() is returning 
>>> true for conditions "aCondition" and "anotherCondition", but the
>>> invoke() method of "myConsequence" is not being called. Even when I 
>>> set my isAllowed() methods to always return true, my invoke()
methods are never reached.
>>> Xerces has no problem validating my XML against my schema, so I'm at

>>> a loss as to what would be causing this.
>>>
>>> Maybe the solution is right under my nose...any ideas?
>>>
>>> Thanks,
>>> Jeff
>>>
>>>       
>
>   

Reply via email to