[jboss-jira] [JBoss JIRA] Commented: (JBRULES-2944) Redeployment of Drools ActionHandler leads to Exception when building rules package (classLoader is not connected to a domain)

[Mark Proctor (JIRA)]

    [ https://issues.jboss.org/browse/JBRULES-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602841#comment-12602841 ] 

Mark Proctor commented on JBRULES-2944:
---------------------------------------

the kbase is not in the archive, only drls and packages. The kbase will generate classes, against it's classloader. If stuff in that classloader changes, because the main app was reloaded, you'll have to throw away the kbase and rebuild another one with the correct classloader, where it will regenerate classes correctly.

> Redeployment of Drools ActionHandler leads to Exception when building rules package (classLoader is not connected to a domain)
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-2944
>                 URL: https://issues.jboss.org/browse/JBRULES-2944
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core
>    Affects Versions: 5.0.1.FINAL
>         Environment: JBoss SOA-P 5.0.0
>            Reporter: Bernd Ruecker
>            Assignee: Mark Proctor
>
> See forum entry as well.
> We have an jBPM 3 Action Handler calling Drools. Drools and jBPM itself are deployed as esb archive. The ActionHandler is part of the application and normally deployed within an EAR (but we tested a plain jar and an esb as well).
> When redeploying the ActionHandler, it leads to an exception, which indicates, that somehow Drools internally have cached an old classloader:
> org.drools.RuntimeDroolsException: java.lang.IllegalStateException:  BaseClassLoader at 14f744d{vfszip:xxx.ear/} classLoader is not connected to  a domain (probably undeployed?) for class  org.drools.base.extractors.BaseObjectClassFieldReader
>     at org.drools.base.ClassFieldAccessorFactory.getClassFieldReader(ClassFieldAccessorFactory.java:152)
>     at org.drools.base.ClassFieldAccessorCache$CacheEntry.getReadAccessor(ClassFieldAccessorCache.java:315)
>      at org.drools.base.ClassFieldAccessorCache.getReadAcessor(ClassFieldAccessorCache.java:245)
>      at org.drools.base.ClassFieldAccessorStore.wire(ClassFieldAccessorStore.java:379)
>      at org.drools.base.ClassFieldAccessorStore.merge(ClassFieldAccessorStore.java:270)
>      at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:739)
>      at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:515)
>      at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:25)
>      at xxx.jbpm.actions.FireRules.createRulesContext(FireRules.java:94)
>      at xxx.jbpm.actions.FireRules.executeAction(FireRules.java:51)
>      at xxx.jbpm.actions.AbstractGeneralActionHandler.execute(AbstractGeneralActionHandler.java:43)
>      at org.jbpm.graph.def.Action.execute(Action.java:118)
>     ....
> I have seen that the code around this has changed in 5.2-SNAPSHOT, but I am not sure, if that fixes the problem and I cannot easily test this. Could somebody of you have a look? Otherwise it is a serious bug!
> Quick addition: We had the problem not only when adding rules from DRL files but as well when using Guvnor.
> Thanks
> Bernd

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira