[rules-users] Unable To Resolve Object Type

[Paul O'Connor]

I have a Drools web service that I wrote using Axis2 version 1.1. Upgrading
to Axis2 1.1 breaks rule compilation with a "Unable To Resolve Object Type"
error enumerated below:

org.drools.rule.InvalidRulePackage: Unable to resolve ObjectType 'Product'
Unable to resolve ObjectType 'Account'
Unable to resolve ObjectType 'Product'
Unable to resolve ObjectType 'Account'
Unable to resolve ObjectType 'Product'
Unable to resolve ObjectType 'Account'
Unable to resolve ObjectType 'Product'
Unable to resolve ObjectType 'Account'
Unable to resolve ObjectType 'Product'
Unable to resolve ObjectType 'Account'
Unable to resolve ObjectType 'Product'
Unable to resolve ObjectType 'Account'
Unable to resolve ObjectType 'Product'
Unable to resolve ObjectType 'Account'
Unable to resolve ObjectType 'Product'

And there is a suspicious reference to a Drools class missing in the
compiler error message:

Rule Compilation error Class "org.drools.spi.KnowledgeHelper" not found
Class "o
rg.drools.spi.KnowledgeHelper" not found Unknown variable or type "result"
Class
 "java.lang.Object" has no method named "setBasisPoints" Expression "result"
is
not an rvalue Expression "result" is not an rvalue Expression "result" is
not an
 rvalue Unknown variable or type "result" Unknown variable or type "result"
Clas
s "java.lang.Object" has no method named "setReason" Expression "result" is
not
an rvalue Expression "result" is not an rvalue Expression "result" is not an
rva
lue Unknown variable or type "result" Exception:14 errors while compiling
unit "
com/foo/bar/Rule_Bump_Rate_22_0.java"

My First thought was that there was a classloader scoping issue introduced
in Axis2 version 1.1. Axis2 uses a standard appserver deployment classloader
architecture to enable service isolation. I was, however, able to confirm
that the classes in question are indeed loaded by the deployment
classloader. This code segment:

Class clazz = null;
ClassLoader cl = this.getClass().getClassLoader();
clazz = Class.forName("com.foo.bar.Account", true, cl);
System.out.println("CL: " + clazz.getClassLoader());
clazz = Class.forName("com.foo.bar.Product", true, cl);
System.out.println("CL: " + clazz.getClassLoader());
clazz = Class.forName("com.foo.bar.Result", true, cl);
System.out.println("CL: " + clazz.getClassLoader());
clazz = Class.forName("com.foo.bar.RequestedBump", true, cl);
System.out.println("CL: " + clazz.getClassLoader());
clazz = Class.forName("org.drools.spi.KnowledgeHelper", true, cl);
System.out.println("CL: " + clazz.getClassLoader());

Yields this at run time:

CL: org.apache.axis2.deployment.DeploymentClassLoader at 1903e13
CL: org.apache.axis2.deployment.DeploymentClassLoader at 1903e13
CL: org.apache.axis2.deployment.DeploymentClassLoader at 1903e13
CL: org.apache.axis2.deployment.DeploymentClassLoader at 1903e13
CL: org.apache.axis2.deployment.DeploymentClassLoader at 1903e13

Incidentally, putting all of the Drools classes in the system classpath
alleviates the problem...

I don't know enough about what is going on with classloading during the rule
compilation to speculate and/or deal with the Axis2 list intelligently. Can
someone postulate a theory?

Thanks in advance!