There is a performance issue in the drools codebase, caused when the drools jbpm jars are not included.
When a stateful or stateless knowledge session is created within drools the drools code base will attempt to create a process runtime and attach it to the session (twice for stateful). The creation is handled by the ProcessRuntimeFactory class which uses org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl as the default provider.
We do not support the drools jbpm code within SOA so the associated jars are not present. The result of this is that every attempt to create a session will result in at least one attempt to load the non-existent class, cause an exception to be thrown and will then return a null for the runtime.
In ESB we can workaround this by checking to see if the provider has been set and, if not, register a default provider. This can immediately return null rather than go through the classloading/exception route.