drools-legacy

Improve classloader behavior in J2EE container - BaseApplicationDataFactory

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.1, 2.5
  • Fix Version/s: None
  • Component/s: all
  • Labels:
    None
  • Environment:
    Platform - JBoss with scoped classloader enabled. Could affect other J2EE containers and applications that uses multiple classloaders.

  • Number of attachments :
    1

Description

Specifically, I have an EAR that with a JMX control that executes Drools code. The JMX control can be invoked via JBoss' JMX console. This causes an Exception as the code for the JMX control is loaded by the EAR classloader – A classloader that is not available to the Jboss's JMX execution thread.

I noticed the code in BaseApplicationDataFactory tries to access the Classloader of the "current thread" and only if that is null, then it fallsback to the "current class" classloader. This change will tell BaseApplicationDataFactory to try another classloader if the first one throws a ClassNotFoundException.

This improves class loading, as we will try both classloaders to see if we can load the desired class.

There are other similar issues such as DROOLS-375. Note I have not attempted to provide a general solution to this problem (such as a DroolsClassloader impl).

Activity

There are no comments yet on this issue.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated: