2010/9/19 Kinjal Khandhar <kinjal.khandhar(a)gmail.com&gt;           import org.drools.audit.WorkingMemoryFileLogger;           WorkingMemoryFileLogger logger = new WorkingMemoryFileLogger( session );           logger.setFileName( "event" );            ... fireAllrules()...           logger.writeToDisk(); Package org.drools.audit.event contains Filter classes; you may pass suitables instances to logger.addFilter() to reduce the volume on the log file. You should probably use an ActivationLogEventFilter permitting the creation and firing of Activations. The former will tell you which conditions were fully evaluated, and the latter which rules were fired. (A WorkingMemoryLogEventFilter permitting nothing will keep WM operations at bay.) Or, you could set up a event listener (implementorg.drools.event.rule.AgendaEventListener), and see org.drools.event.rule for the subinterfaces of ActivationEvent. This saves you the bother of processing the XML log file, and you'll get the Rule information easily enough: ((ActivationEvent)event).getActivation().getRule().getName() and ...getPackageName() Since you'll only need Sets of activations and firings, this approach may be preferable. To learn which rules were never activated, you can access the Knowledge Packages in your Knowledge Base, iterate over the rules and create a set of all rules; subtracting those from the log will give you the required information. -W

On 15 November 2010 19:30, kkinjal <kinjal.khandhar(a)gmail.com&gt; wrote: This has been frequently asked for, and the answer is "no". Conditions are munched by the compiler/Rete builder, and there's no simple way of tracking what goes on during this process. The network is too complex for easy inspection by a debugger. Moreover, CEs may depend on bindings from preceding CEs, so the idea of having additional rules for all individual conditions isn't sufficient. What might do the trick is to write for a "production" rule rule r A(...) B(...) C(...)... then...end additional rules rule r-1 A(...) then...end rule r-2 A(...) B(...) then...end rule r-3 A(...) B(...) C(...) then...end ... and observe the agenda entries for these; if, say, r-1 and r-2 are around but r-3 isn't, then C(...) is currently failing. Subsequent conditions D(...) arent't relevant at this moment. I think that these rules could be derived from the initial rule r (relying on very internal API calls). Any takers? ;-) OTOH, if your CEs are simple and straightforward, a few queries might be sufficient to provide enough data for telling you what iCE s not true. -W