[esb-issues] [JBoss JIRA] Updated: (JBESB-3402) LHS of rules failing to match on ESB redeploy

[ https://jira.jboss.org/browse/JBESB-3402?page=com.atlassian.jira.plugin.s... ] David Ward updated JBESB-3402: ------------------------------ Description: It became evident that Drools caches ClassLoaders by default. The problem that showcased this was that on redeploy of the business_rules* quickstarts, none of the LHS of the DRL rules were matching. When we deploy a new ESB archive, there is a new ClassLoader. However Drools was holding onto the old ClassLoader. Because an Object is only ever "equal" to another Object if it came from the same ClassLoader, none of the Objects on the LHS matched the expression. Two things need to happen to fix this problem: 1. KnowledgeBuilderConfigurations need to be created with a Properties argument containing ClassLoaderCacheOption.PROPERTY_NAME="false". 2. KnowledgeBuilderConfigurations need to be created with a ClassLoader argument containing a custom ESB ClassLoader, which under-the-hood uses the LifecycleResource mechanism to associate the original Thread ContextClassLoader (the deployment's ClassLoader) with calls to loadClass(), findResource(), etc. Luckily most of what is needed here already exists in the DroolsRuleAgentHelper code. was: It became evident that Drools caches ClassLoaders by default. The problem that showcased this was that on redeploy of the business_rules* quickstarts, none of the LHS of the DRL rules were matching. When we deploy a new ESB archive, there is a new ClassLoader. However Drools was holding onto the old ClassLoader. Because an Object is only ever "equal" to another Object if it came from the same ClassLoader, none of the Objects on the LHS matched the expression. Two things need to happen to fix this problem: 1. KnowledgeBuilderConfigurations need to be created with a Properties argument containing ClassLoaderCacheOption.PROPERTY_NAME="true". 2. KnowledgeBuilderConfigurations need to be created with a ClassLoader argument containing a custom ESB ClassLoader, which under-the-hood uses the LifecycleResource mechanism to associate the original Thread ContextClassLoader (the deployment's ClassLoader) with calls to loadClass(), findResource(), etc. Luckily most of what is needed here already exists in the DroolsRuleAgentHelper code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira