Hiya,
You've noticed correctly. The scope is cached with the process rather than the process instance id. It's a performance trade-off and I do need to document it better. I'd certainly intended to make it configurable (there's a cacheScope field but I haven't put a setter onto it, yet) but basically, it would be bad (as in "don't cross the streams") to use process global variables by just putting them at the top level scope of the script. None of the examples do but it's definitely not clear enough. The justification is:
* For most things, you shouldn't need to use process global variables
* It's _way_ faster
cheers,
j.
Great! thanks.
While I am at this, may I post another question. I was reading source code from cvs and down there in processExecutor, in the getScopeCached method, the scope seems to be cached with process id rather than process instance id. Does this mean that you can only have one process instance running at the same time? otherwise how do you prevent the multiple instances from using the same scope and polluting it? or is this something the Rhino does internally?
Thanks.
Ah, that's an outstanding defect, i.e. limiting the outstanding tasks to a particular user or role. I'll prioritise that for an upcoming release. That and more documentation on it.
cheers,
j.
qxcfg wrote:
Thanks. Are the user(or role) concept integrated with the worklist and task management? it does not seem that setting the role for a task affect who gets the task. Again, some document on this would be greatly appreciated.
dkfn wrote:
BpmScript uses Acegi for it's user management. Currently it just points to an inmemory set of user names and passwords set up in the spring applicationContext. You should be able to configure it to point to most security stores by changing that config.
qxcfg wrote:
How are user/role managed in BPMScript (is there a web console for this) Also how do the javascript tasks calls get converted to the task web forms? Is there documentation for these. Thanks.
