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