Thanks for the explanation, Mark. Sorry if it appeared that the focus of my poorly worded question was why Strings were used for the key. Using Strings makes total sense to me. I was really just trying to better understand how caching is implemented to help me better understand why I'm having the problem I originally posted about. Can you explain to me how, through the JBoss Rules API, I can always ensure that I'm not picking anything up from an internal cache when I deploy new rules? I want to always make sure that the rules from the new drl file I place in the classpath are always picked up, not anything that was previously cached internally by JBoss Rules. Thanks. Keith On Wed, Jul 9, 2008 at 9:15 AM, Mark Proctor <mproctor@codehaus.org> wrote:We generate bytecode readers for performance, it would be possible to plugin a reflection based reader that would avoid this issue, but we don't have plans to this due to time - we would accept a patch. With regards to why the String for the key, why not? What other key would you imagine we should keep? I guess we could alos look into a classloader specific var to hold the cache. Shows the classes we use to generate field accessors. http://fisheye.jboss.org/browse/JBossRules/tags/4.0.7.19894.GA/drools-core/src/main/java/org/drools/util/asm If you do an import of the project into eclipse you can see where those classes are used from and maybe come up with a solution - please make sure there are no performance loses. Mark Keith Bennett wrote:I found a link that might explain what is happening with the problem I described in another posting (included below): http://jira.jboss.com/jira/browse/JBRULES-1009 Mark Proctor, if you read this posting, can you please explain in more detail how and why JBoss Rules generates bytecode field readers and caches them by string name? I would appreciate it. Could this explain the issue I'm experiencing as described below? I have scoured the documentation and have tried many different approaches to solving this problem, to no avail. I absolutely can not get the new version of a .drl file to load with just an application restart in Tomcat. I have to restart Tomcat each time. In my mind, this has to be a classloader issue. I just don't know how to get around it. I would really appreciate any help! Keith ---------- Forwarded message ---------- From: Keith Bennett <forthwind@gmail.com> Date: Wed, Jul 2, 2008 at 9:47 AM Subject: New rules in source file not loaded when application redeployed To: Rules Users List <rules-users@lists.jboss.org> I am packaging my rules as a drl source file in a jar that is then bundled in a war file that is then deployed to Tomcat. In my implementation, the rulebase is cached the first time it is used in my application, but when I add new rules to the source file and rebuild my application then redeploy it on Tomcat, the new version of the rules don't get loaded into the rulebase. Why and how is an older version of the rules being loaded into the rulebase when I redeploy my application in Tomcat? As FYI, I have developed a business rules service that initializes the rulebase upon a Spring container startup by loading the drl file from the classpath. Is there an internal Drools static cache that is scoped to something other than my application? The only thing I can do to load the new rules is restart Tomcat. When I do this, the new version of the drl source file is loaded and used, so I'm thinking the problem I'm having is somehow related to the class loaders Tomcat uses, but I can't find information about what Drools might be doing internally with a static cache or something like that. Can anyone explain what might be happening and how to configure Drools and/or my application to get around this problem I'm having? I definitely appreciate any help you can provide! 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_______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users