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-cor...
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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users