Tuesday, February 19, 2008

Looking under Drools' skirt

As most users know, during rule compilation, Drools generates several classes in Java to represent rule consequences and semantic blocks of code. Although, for performance reasons, this whole process occur in memory and no content is dumped to the filesystem.

We had a few requests in the past to expose the generated code in some way, so that the users can look at it and eventually understand what is happening behind the scenes. Since this is a useful feature for debug sessions too, I just added a configuration parameter to allow users to dump the generated Java code to disk.

In order to do that, just set the "drools.dump.dir" property with the root directory where you want files dumped:

java -Ddrools.dump.dir="some/root/dir" ...

Or use the PackageBuilderConfiguration API:

PackageBuilderConfiguration conf = new PackageBuilderConfiguration();
conf.setDumpDir( new File( "some/root/dir" ) );
PackageBuilder builder = new PackageBuilder( conf ) ;

It is important to remember that depending on your rules, Drools may generate several files. It will use the provided root directory as the base directory and will create subdirectories as needed and defined by the usual Java package directory structure.

This is available both in 4.0.x branch (to be released in version 4.0.5) and trunk (to be released in 5.0.0).

Enjoy.
Edson

4 comments:

  1. I tried using this feature with 4.0.6 and got following exception:


    java.lang.NoClassDefFoundError: org/mvel/AbstractParser
    at org.drools.rule.builder.dialect.mvel.MVELDialect.setLanguageLevel(MVELDialect.java:128)
    at org.drools.rule.builder.dialect.java.AbstractJavaBuilder.%clinit%(AbstractJavaBuilder.java:26)
    at org.drools.rule.builder.dialect.java.JavaDialect.%init%(JavaDialect.java:78)
    at org.drools.rule.builder.dialect.java.JavaDialectConfiguration.getDialect(JavaDialectConfiguration.java:62)
    at org.drools.compiler.PackageBuilderConfiguration.buildDialectRegistry(PackageBuilderConfiguration.java:175)
    at org.drools.compiler.PackageBuilder.%init%(PackageBuilder.java:142)
    at org.drools.compiler.PackageBuilder.%init%(PackageBuilder.java:108)



    Do I need to update my mvel libraries (using maven)?

    ReplyDelete
  2. yes, you must use the version of the dependencies as specified by the release.

    ReplyDelete
  3. Solved issue above - mvel 1.2.24-java1.4 library at repo1.maven.org/maven2 seems to be wrong, (has the AbstractParser under org.mvel.compiler.AbstractParser) ...got it from repository.jboss.com/maven2 and it works fine

    ReplyDelete