So I did further testing and I was able to narrow it down.
Somehow the culprit is with the import statements. My DRL file has a
package name of:
package com.test.abc
dialect "mvel"
So, it appears that in drools using MVEL, a fully qualified name is
required to instantiate the class? It's quite strange though.
Considering that I'm following the docs, I should be able to
dynamically create a new type declaration instance without qualifying
it.
The following somehow works:
then
insert(new com.test.abc.Domestic());
end
Why is drools/mvel being so strict?
-ck
On Mar 15, 2009, at 4:23 AM, CK wrote:
Hi,
I'm wondering if I am doing something wrong in my code:
I create dummy type declarations to indicate presence of certain
states (is there possibly a better way of doing this?):
declare Domestic
dummy : boolean
end
declare Multiple
dummy : boolean
end
rule "..."
when
......
then
insert(new Domestic());
end
Something like this is giving me the following errors during DRL
file parsing:
Unable to build expression for 'consequence': Failed to compile: 1
compilation error(s):
- (0,0) could not resolve class: Domestic ' insert(new Domestic());
Based on what the docs say, this should generate the proper dynamic
classes and I should immediately be able to use the declared types.
I did additional checking by outputting the registered Type
Declarations. These two types are indeed registered in the
PackageBuilder.getPackage().getTypeDeclarations().
So I can only guess that either I'm doing something wrong here or
there is a bug in the CR1 release.