Patrick van Kann wrote
So my questions are:
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
as an
optional module? Or users can just recreate them from the document of
course.
Cheers
Pat
2011/1/13 Mark Proctor mproc...@codehaus.org
On 13/01/2011 01:49, Mark Proctor wrote:
On 12/01/2011 20:20, Patrick van Kann wrote:
Hi Mark,
I'm not sure if this the kind of example you mean, but here
Hi Mark,
I'm not sure if this the kind of example you mean, but here is a blog
article I wrote describing how I integrated Drools, JSR 303 and Spring to
deliver rules-based bean validation for use in a Spring MVC web app, for
example.
Hello fellow Droolers,
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).
I just wanted to update those interested with the answer and ask some
further questions, probably aimed at any
Hello,
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.
I've defined 2 knowledge sessions from the same knowledge base in the app
context - one stateless, one stateful but otherwise identical. They
I might be putting too simplistic an interpretation on this, but this is
what the Javadoc says for StatelessKnowledgeSession
StatelessKnowledgeSession provides a convenience API, wrapping
StatefulKnowledgeSession. It avoids the need to call dispose(). Stateless
sessions do not support iterative
