Hello fellow Droolers,<br><br>A while ago I asked why the <drools:batch> element seemed to work differently in the case of a StatelessKnowledgeSession and a StatefulKnowedgeSession (see below).<br><br>I just wanted to update those interested with the answer and ask some further questions, probably aimed at any developers who happen to be reading.<br>
<br>I checked out the 5.1.1.34858 tag and had a look at how the Spring integration works. I found that the reason that the global is not set in the case of a StatelessKnowledgeSession is because the <spring:batch> element is effectively ignored in the StatelessKnowledgeSessionBeanFactory, which lacks the following code present in the StatefulKnowledgeSessionBeanFactory (in the internalAfterPropertiesSet() method):<br>
<br>if ( getBatch() != null && !getBatch().isEmpty()) {<br> for ( Command<?> cmd : getBatch() ) {<br> ksession.execute( cmd );<br> }<br>}<br><br>So, either by accident or design the <spring:batch> element has no effect when using a StatelessKnowledgeSession (but is perfectly allowable in the XSD/Spring namespace).<br>
<br>So my questions are:<br>1) Is this the intended behaviour or a bug? On reflection, I am now not sure the idea of a "batch/script" makes sense for a StatelessKnowledgeSession since execute() is a one-shot method and any globals set this way would not be available to later executions, which is what I was looking for.<br>
2) If so, should the XSD be changed to disallow the batch element within a stateless session (difficult, given that this is determined via the "type" attribute) or should the documentation simply warn people that the <spring:batch> element doesn't do anything if you set the type attribute to stateless (somewhat confusing, I suppose)<br>
3) If not, should the code above be added to the StatelessKnowledgeSessionBeanFactory.internalAfterPropertiesSet() method? <br>4) Should there be another way to declare a global that isn't through the batch element (one that would cause globals to be set via the setGlobal(String, Object) method rather than using the SetGlobalCommand via the execute() method.<br>
<br>I am happy to try and contribute something along these lines if I can get some guidance as to what was actually intended.<br><br>Hope this helps and thanks again for Drools.<br><br>Patrick<br><br>=====================================<br>
Hello,<br><br>I've been trying out the Spring integration package in Drools 5.1.1 and it works really well, but I have run into one issue I can't figure out.<br><br>I've defined 2 knowledge sessions from the same knowledge base in the app context - one stateless, one stateful but otherwise identical. They both refer to a collaborator defined as a bean in the app context which is to be used as a global in my rules. This is just an excerpt of my full Spring context, the kbase definition itself is not an issue.<br>
<br><bean id="applicantDao" class="com.acme.app.dao.impl.ApplicantDaoImpl" /><br><br><drools:ksession id="statelessKSession" type="stateless" name="statelessKSession" kbase="kbase"><br>
<drools:batch><br> <drools:set-global identifier="applicantDao" ref="applicantDao" /><br> </drools:batch><br> </drools:ksession><br> <br> <drools:ksession id="statefulKSession" type="stateful" name="statefulKSession" kbase="kbase"><br>
<drools:batch><br> <drools:set-global identifier="applicantDao" ref="applicantDao" /><br> </drools:batch><br> </drools:ksession><br><br>The issue is that this configuration works for the stateful but not the stateless session, in the sense that the stateful session appears to have a valid reference to the applicantDao object in the Globals object but the stateless session doesn't.<br>
<br><at> Test<br>public void testStatelessGlobal() {<br> Globals globals = statelessKSession.getGlobals();<br> Object global = globals.get("applicantDao");<br> Assert.assertNotNull(global);<br>
}<br> <br><at> Test<br>public void testStatefulGlobal() {<br> Globals globals = statefulKSession.getGlobals();<br> Object global = globals.get("applicantDao");<br> Assert.assertNotNull(global);<br>
}<br><br>The first test fails (the global variable is null) but the second passes. No errors are thrown by Drools during the setup of the Spring container.<br><br>What am I doing wrong? Should I be able to define globals in this way for stateless sessions? The XSD seems to indicate this is a valid configuration, but it just doesn't work.<br>
<br>Is anyone else working with the Spring integration that can point out my error here?<br><br>Many thanks,<br><br>Patrick<br>