[rules-users] Caching of JBoss Rules bytecode field readers

[Keith Bennett]

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 at 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 at 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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>