[rules-users] Unable To Resolve Object Type

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@1903e13 CL: org.apache.axis2.deployment.DeploymentClassLoader@1903e13 CL: org.apache.axis2.deployment.DeploymentClassLoader@1903e13 CL: org.apache.axis2.deployment.DeploymentClassLoader@1903e13 CL: org.apache.axis2.deployment.DeploymentClassLoader@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!