Scott, Well, I won't be able to deploy any changes until the end of today due to user testing that is going on right now, but I will do what you suggested. In the mean time, can you explain when I deploy a new .drl file, packaged within a jar file, as part of my web application why/how a compiled version of the old rules might be picked up? I understood up to this point that when I deployed the new .drl file, restarted my application in Tomcat, and via Spring re-initialized my service that lazy initializes the RuleBase that the new rules would be picked up from the file in the classpath, not a different compiled version. Is the compiled version (i.e., the previous version of the .drl file) serialized or cached on the server somewhere? I've been confused as to how the old rule was firing after I verified that it no longer existed in the new .drl file that was redeployed to Tomcat. How can I prevent a previously compiled version from being used? I definitely don't want that to happen. The only thing that fixed this problem for me was restarting Tomcat, which isn't practical, of course, in our production environment. Keith On Tue, Jun 24, 2008 at 9:15 PM, Scott Reed <sreed@avacoda.com> wrote:Can you verify that you are not running a compiled version of the old rules (perhaps by adding System.out.println("New version"); to the LHS in the new rules)? Keith Bennett wrote:Does anyone have any idea why drools.getRule().getName() inside of the rule consequence would be returning the old business rule name? I renamed the business rule, and I am seeing through testing that the old name is being resolved by Drools at runtime, not the new one. What the heck is going on? I am using the Drools 4.0.7 libraries. Keith_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users