I am kind of lost by the line numbers and changes you mentioned. Maybe
you can submit a code patch? This way we can see exactly what is being
changed, discuss the impact if it is the case, and apply it to the codebase.
Was this the fundamental problem with templates
There are a few issues on how templates were implemented. The main one,
and probably the main reason we did not extended the functionality to
support any underlying fact format, is the syntax support on semantic code
blocks. I.e. dialect support, specially on consequences. For instance,
imagine that you want to read the attribute "age" from the "Person"
the consequence of a rule. Ideally, you want to do something like bellow,
does not matter what the underlying format of Person is. After all, Person
is a fact:
$p : Person(...)...
int age = $p.age;
Above will work for java and MVEL, if the format is POJO. Now with
templates, you must do something like:
int age = ((Integer) $p.getAttribute( "age" )).intValue();
Now, imagine that your fact is an XML element, or a database record? In
the end, your rules will be tied to the underlying format and format
pluggability will lose much of its value.
So, the big issue, IMO, is that we must implement format transparency on
the semantic code blocks. Implementing format support for non-semantic
blocks is pretty straight-forward and the proof-of-concept is that we do it
already (although not extensively tested) with templates.
But don't give up. :) It is possible to do it, we just lack manpower to
do all we want, and if it is something you will use, we can work together
using an incremental approach. First we make sure everything is correctly
wired and working for multiple underlying formats, and then we deal with the
Regarding merge of packages, it is quite simple. You can merge packages
either at compilation time, by using the package builder and adding your
prereq artifacts first, or directly at rulebase building time by adding
multiple packages. Also, Mark did an extensive work on binary references
rewiring a couple of weeks ago to ensure we have a clean binary in-memory
structure, without classloader leaks.
2008/8/27 Stephen Kestle <stephen.kestle(a)orionhealth.com>
This is a follow up to my reply to
What I would like are some changes to PackageBuilder (line numbers at
Remove/change lines 632-641 as they call
pkgRegistry.getPackage().getFactTemplate, where fact templates are compiled
into the package after 393, which is after 381->551->570->634. Ok, so
perhaps it is possible, if you define your templates in another package...
Change TypeDeclaration.Format to a class, instead of an enum. We want our
own type. At line 632, insert something like the following:
final String format = ObjectUtils.defaultIfNull(typeDescr.getMetaAttribute(
TypeFactory factory = packageDesc.getTypeFactory(format); //where packages
have a typeFactory declaration of a class that implements TypeFactory (which
has a getFormat() for registration purposes)
TypeDeclaration type = factory.create(typeDescr);
lines 643-674 get moved into PojoTypeFactory.create();
Something needs to be done to TypeDeclaration to allow non-class based
implementations. After all, it makes no sense (to me) to call a method that
then just refers to a map of name-values.
However, drools uses java object types/classes heavily for rules
optimisations - and type references. Is this unavoidable? Was this the
fundamental problem with templates - that one could not be composed inside
another because the type could not be referenced (by a class)?
Also, I'm looking for a way to do partial compilation... I want to create a
description with fundamental declarations and imports for our product to
simplify the text ones, but I can't figure out how to merge - is it just a
case of declaring my core package, and then "adding" the same one from the
rules-dev mailing list
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com