Patrick van Kann wrote
So my questions are:
1) Is this the intended behaviour or a bug? On reflection, I am now not
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
be available to later executions, which is what I was looking for.
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
element doesn't do anything if you set the type attribute to
stateless (somewhat confusing, I suppose)
3) If not, should the code above be added to the
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
the execute() method.
I was also interested in making this feature work, so I had a look.
The code you suggest is a good start, but is not enough : as you suggest,
the setGlobal method has to be called.
My understanding is that all executions on a stateless sessions are
stateless, including the commands. Which means, if you execute commands,
the session will be "disposed" at the end, which undoes the command
executions. The answer to your questions 1, 3 and 4 is "Yes" I think.
See the attachment for a working patch.
P.S. : I know this answer comes 2 years after your question, but maybe other
people will look for a solution in the future.
View this message in context:
Sent from the Drools: User forum mailing list archive at Nabble.com