KieContainer kcont = ks.newKieClasspathContainer(getClass().getClassLoader());
KieBase kbase = kcont.getKieBase("sampleKBase");
As you have mentioned in your email, this is a static approach as we load the resources before to create a KieSession and fire the rules.
2. Your example code calls .newKieSession() on a kbase object as opposed to
a kContainer object. Is there a reason why? If I create a new KieSession
from a kbase vs. kContainer, will I still be able to rebuild the kjar
dynamically in the code and keep using the same stateful session?I need that Mario Fusco or Marc Proctor confirm what I will say here (or somebody) else but I suspect that if you create a session on the KieContainer level and not on the KieBase could allow you to support increment as this unit test show you (
https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/IncrementalCompilationTest.java#L660) without having to recreate a new session (stateless)
3. It looks like I'll have to wait until Drools 6.1.0 to get the parameter
to specify a classloader when creating the container? I see you just added
that recently. I've tried usingThread.currentThread().setContextClassLoader(...) but can't seem to make
that work with Drools 6.0.1 in Karaf 2.3.3 because thenRuleBaseConfiguration sets the classloader and uses it to try resolving
org.drools.core.conflict.DepthConflictResolver, which it can't do because
it's no longer using the OSGi classloader.