@Anatoly, Thanks for the feedback. I don't see this, any more than with any other data. If the WorkItem or WorkItemManager interface supplied a getGlobal(String name), and the WorkItemHandler doesn't stuff it away in a field or otherwise retain it as state, then it's not stateful - unless I'm missing something. Yes, if I must. But some resources used by workitems need to be configured by either the process initiator or a process participant, yet don't make sense in the variable domain. Consider, e.g., a process where multiple workitems need to access a database - but the selection of database is up to the process initiator. The connection credentials don't really belong in a variable, at least as I understand the intended uses for globals and variables. -Ed -- View this message in context: http://n3.nabble.com/Access-to-globals-from-WorkItemHandlers-tp732460p732... Sent from the Drools - User mailing list archive at Nabble.com.

@Anatoly, tolitius wrote: That's true - but exactly the same, I believe, as in code under the right-hand-side of rules. The engine doesn't know if a rule mucks with the internals of a global either. "Don't run with scissors in your hand" shouldn't lead to the abolition of scissors on alternate Saturdays. tolitius wrote: Sorry, but I'm not sure what you're getting at... in the case I described, the credentials are supplied by the initiator of the process. Where exactly are you envisioning them being stored? In my case, the data is analogous to database credentials - not actually them - so specific design idioms that are specific to them aren't relevant. The credentials are for access to a thick access library that has its own data-access architecture. Touma wrote: This only provides mapping to and from variables. What you're suggesting is, I think, exactly what I was asking for! -Ed -- View this message in context: http://n3.nabble.com/Access-to-globals-from-WorkItemHandlers-tp732460p732... Sent from the Drools - User mailing list archive at Nabble.com.

tolitius wrote: Anatoly, Forget about flow, for the moment, and just consider rules. If you could roll back time, and didn't have to consider backward-compatibility, would you eliminate the ability to use globals in rule right-hand-side code? If not: Why not? And does the same logic not apply to the WorkItemHandler context? Is your message that "use of globals in any user code (rule right-hand-side or WorkItemHandler) is strongly deprecated, regardless of whether any alterations are made?" That's my interpretation. -Ed -- View this message in context: http://n3.nabble.com/Access-to-globals-from-WorkItemHandlers-tp732460p732... Sent from the Drools - User mailing list archive at Nabble.com.

tolitius wrote: Anatoly, It would, technically. It's actually a marketing problem that I'm trying to avoid! We are by no means settled on Drools. There are a lot of horror stories about rule-engine performance, and Drools in particular. I'm sure that most of them are based on bad design choices... but I'd like to avoid any smell of unnecessary rule-engine overhead. You probably can see where I'm going... in a forward-chaining engine like Drools, every introduction or mutation of a variable requires matching against the active rules. In the context of a normal workflow, I believe that this overhead is ridiculously trivial in the kind of use-case I've been talking about. But I'd prefer to avoid the discussion altogether! -Ed -- View this message in context: http://n3.nabble.com/Access-to-globals-from-WorkItemHandlers-tp732460p733... Sent from the Drools - User mailing list archive at Nabble.com.