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?
alex
