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.
Matthieu
>
> 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
> >
>
