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.
alex
On Wed, May 7, 2008 at 9:06 AM, Tammo van Lessen <[EMAIL PROTECTED]>
wrote:
> Matthieu Riou wrote:
>
> > On Wed, May 7, 2008 at 8:10 AM, Tammo van Lessen <[EMAIL PROTECTED]>
> > wrote:
> >
> > > a) What is the scenario for deploying a retired process? Isn't that
> > > handled by process versioning?
> > >
> >
> > That was in the old sense of retiring, when retiring was actually what
> > we
> > call deactivating now. The idea was that you could deploy processes
> > without
> > wanting them to be active in the engine, I'm not aware of anybody
> > wanting
> > this feature so I wouldn't mind removing it (especially now that we have
> > dehydration).
> >
> > a1) I'm a correctly assuming that <active> and <retired> model a
> > > tri-state
> > > attribute?
> > >
> >
> > I have hard time figuring out what a non-retired non-active state would
> > be.
> >
>
> Wouldn't this simply be 'inactive'?
>
> | active | retired | meaning
> ------------------------------------------------------
> | false | false | process deployed but inactive,
> | | | could be enabled via PMAPI
> ------------------------------------------------------
> | true | false | process deployed and active,
> | | | could be disabled/retired via PMAPI
> ------------------------------------------------------
> | false | true | process deployed but retired,
> | | | i.e. old instances are kept running but
> | | | instantiation of new ones is not possible
> ------------------------------------------------------
> | true | true | see (false, true)
> ------------------------------------------------------
>
> So IMO the last two state are actually the same and boil down to "active"
> (2), "inactive" (1), "retired" (3,4). Or am I mistaken?
>
> So for the trunk I'm in favour of dropping the retired attribute.
>
>
> IIRC (and maybe I don't) at this stage the process hasn't been compiled
> > yet.
> > So it's a chicken-and-egg problem.
> >
>
> True. But in case we could solve it, e.g. by preparsing the BPEL file, we
> could get rid of the filename attribute in the DD (and can then find BPEL
> files by QName). I think its currently a bit strange that you don't have to
> put the filename into the DD unless you want to have custom properties
> compiled into the process while everything else is assigned automatically...
> Nothing critical actually. A JIRA?
>
> Cheers,
> Tammo
>
