Alex Boisvert wrote:
On Wed, May 7, 2008 at 11:11 AM, Matthieu Riou <[EMAIL PROTECTED]>
wrote:
On Wed, May 7, 2008 at 10:58 AM, Alex Boisvert <[EMAIL PROTECTED]>
wrote:
The "retired" state prevents new instances from being created.
The "inactive" state prevents any execution at the process definition
level. It was means to be the equivalent of a "global suspend" on the
process definition.
It's correct to say that {active=false, retired=true} and {active=false,
retired=false} have the same functional behavior, although there's
benefit
in separating the two states because you can simply change
active/inactive
state without having to remember if the process was retired or not.
Yep. What I'm questioning is whether making active/inactive public (part
of
the deployment descriptor) is pertinent. AFAIK it's not a feature anybody
ever asked for, let alone use.
Agreed. It seems both of these states should be part of the persistent
state of the process definition in the ProcessStore, but not necessarily
exposed in the deployment descriptor. Is that what you meant?
That's particularly what I meant :) These states definitely make sense
after the deployment but I was missing a scenario where I want to
initially deploy a retired model. The active state makes sense if I want
to deploy a bunch of process models that I want to selectively activate
later using the PMAPI (more in terms of activating the service endpoint,
as the number of process models is actually not an issue).
Cheers,
Tammo
