The getters are generated by this class:
http://fisheye.jboss.org/browse/JBossRules/branches/4.0.x/drools-core/src/main/java/org/drools/base/ClassFieldExtractorFactory.java?r=15671
It creates a ClassLoader using the RuleBase classloader as the parent.
The generated classes are also stored in the cache:
http://fisheye.jboss.org/browse/JBossRules/branches/4.0.x/drools-core/src/main/java/org/drools/base/ClassFieldExtractorCache.java?r=15671
However this cache is a singleton so I guess if you have two rulebases
which reference different threads and then you execute on another thread
- the cache is on the executing thread, the code generation on the
referenced threads.
mark
Keith Bennett wrote:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
