Thanks for the fast response! I'll attempt to post as much as I can, splicing out any case specific info. The Java code surrounding my invocation is as follows: ============================= //Get a list of all knowledgebase resources List<File> kbList = config.getCompleteKBList(); //Note that this is a simply a collection of absolute file paths containing DRL and RF files if(kbList == null) throw new FrameworksException("Failed to get list of knowledgebase resources. Configuration returned null"); //Add all of the resources we found for(File file : kbList) { if(file == null) continue; if(log.isDebugEnabled()) log.debug("Adding resource file: " + file.getAbsolutePath()); if(file.getName().endsWith(KB_FILE_EXT)) kbBuilder.add(ResourceFactory.newFileResource(file), ResourceType.DRL); else if(file.getName().endsWith(RF_FILE_EXT)) kbBuilder.add(ResourceFactory.newFileResource(file), ResourceType.DRF); else throw new FrameworksException("Found invalid file in our knowledgebase list! It was: \"" + file.getAbsolutePath() + "\". This extension is not supported"); // Check the builder for errors if (kbBuilder.hasErrors()) { throw new FrameworksException("<" + file.getAbsolutePath() + ">: Unable to compile knowledge base: " + kbBuilder.getErrors().toString()); } } KnowledgeBase kb = kbBuilder.newKnowledgeBase(); kb.addKnowledgePackages(kbBuilder.getKnowledgePackages()); ============================= The above line is the point at which the error occurs. I am using several other rule files, but I have removed them while I am debugging this issue. I am left with simply this rule file: ============================= package <removed>.kb.appliances import <removed>.ApplianceType; import <removed>.ApplianceTypeObject; import <removed>.ApplianceTypeObjectHost; import <removed>.ApplianceTypeIdentifier; import java.util.List; dialect "java"; rule "root_appliance" ruleflow-group 'initialize-appliance-definitions' when not ( ApplianceType ( type == ApplianceTypeIdentifier.APPLIANCE_ROOT ); ); then ApplianceType appliance = new ApplianceType(ApplianceTypeIdentifier.APPLIANCE_ROOT, null); insert(appliance); end; rule "root_host" no-loop true ruleflow-group 'initialize-appliance-definitions' when $app:ApplianceType ( type == ApplianceTypeIdentifier.APPLIANCE_ROOT ); not( ApplianceTypeObject() from $app.getObjectTypes()); then //Do something end; ============================== If there is any more information I can provide please let me know. I believe that is everything. -- View this message in context: http://drools.46999.n3.nabble.com/Issue-with-From-Clause-Class-Cast-Error... Sent from the Drools: User forum mailing list archive at Nabble.com.

Well.. if you remove that line you are not including your rules in the knowledge base :) But the problem is as suspected, a fix was not back-ported. You can either use 5.5 or wait for Mario to follow up shortly with the patched 5.4 Best Davide -- View this message in context: http://drools.46999.n3.nabble.com/Issue-with-From-Clause-Class-Cast-Error... Sent from the Drools: User forum mailing list archive at Nabble.com.

Hi Taylor, I must say I took a while to reproduce this problem. I knew there could be something wrong because I couldn't reproduce it neither on the 5.5.x (master) branch nor on the 5.4.x one and that was weird because I pushed the fix linked by Davide on the master branch but I didn't backport it on the 5.4.x. Moreover, after a deeper look, I realized that the fix was strictly related with a brand new feature I added during the development of the 5.5.0 release (the indexing for comparison constraints) and that's why I didn't backport it to the 5.4.x branch. Nevertheless I also couldn't find any other commit subsequent the deploy of the release 5.4.0.Final that could have been possibly related with your issue. In a word I was pretty sure that the problem you found was still there, so I continued investigating to try to reproduce it. At this point something wrote by Wolfgang in his first reply made me ring a bell: why was removeRule invoked in the stack of your ClassCastException? Actually there are only 2 reasons why a rule should be removed from the KnowledgeBase: either you were explicitly invoking the removeRule() method (and apparently you weren't doing that) or you were adding a rule with the same name (and in the same package) twice and in this case the old rule is automatically removed to be replaced with the new one. In the end I've been able to reproduce the same exception you reported just repeating TWICE the statement: kb.addKnowledgePackages(kbBuilder.getKnowledgePackages()); Indeed the second invocation of addKnowledgePackages() causes the 2 rules to be readded to the KnowledgeBase and to do so the old ones having the same name have to be removed. I then suspect you're involuntarily doing the same in your code and that could also explain why you wrote that removing (I'd say one of the two) addKnowledgePackages() fixes your problem. The bottom line is that the ClassCastException is still there (both on the master and the 5.4.x branches) and I am working just now to fix it. Thanks for having reported it. Cheers, Mario -- View this message in context: http://drools.46999.n3.nabble.com/Issue-with-From-Clause-Class-Cast-Error... Sent from the Drools: User forum mailing list archive at Nabble.com.

I am using 5.4.0 Final Downloaded about a month ago. Specification-Title: Drools :: Core Specification-Version: 5.4.0.Final -- View this message in context: http://drools.46999.n3.nabble.com/Issue-with-From-Clause-Class-Cast-Error... Sent from the Drools: User forum mailing list archive at Nabble.com.