On Wed, May 7, 2008 at 11:45 AM, Tammo van Lessen <[EMAIL PROTECTED]>
wrote:
> 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 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 d
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
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 d
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,
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. T
done. its not perfect as the components have sometimes different names
but I currently don't have the time to tweak the text accordingly...
On Wed, May 7, 2008 at 5:25 PM, Matthieu Riou <[EMAIL PROTECTED]> wrote:
> On Wed, May 7, 2008 at 8:19 AM, Tammo van Lessen <[EMAIL PROTECTED]>
> wrote:
>
>
On Wed, May 7, 2008 at 8:10 AM, Tammo van Lessen <[EMAIL PROTECTED]>
wrote:
> Hi guys,
>
> while thinking about how to model an deploy.xml editor, I stumbled upon
> some elements in the schema I don't really understand.
>
> a) What is the scenario for deploying a retired process? Isn't that
> hand
On Wed, May 7, 2008 at 8:19 AM, Tammo van Lessen <[EMAIL PROTECTED]>
wrote:
> Matthieu Riou wrote:
>
> > The only thing that I have right here is the one attached...
> > >
> > >
> > Me neither, and I think your attachment got lost on the way :)
> >
> Argh :) Next try...
>
I think emzlm is strippi
Matthieu Riou wrote:
The only thing that I have right here is the one attached...
Me neither, and I think your attachment got lost on the way :)
Argh :) Next try...
On Wed, May 7, 2008 at 7:33 AM, Tammo van Lessen <[EMAIL PROTECTED]>
wrote:
> Hi guys,
>
> somehow our architecture figure got lost in confluence, or am I wrong?
> (I'm not sure whether we had one at all at least there are dangling FIGREFs)
>
I don't remember having one. A nice diagram would be c
Hi guys,
while thinking about how to model an deploy.xml editor, I stumbled upon
some elements in the schema I don't really understand.
a) What is the scenario for deploying a retired process? Isn't that
handled by process versioning?
a1) I'm a correctly assuming that and model a
tri-sta
Hi guys,
somehow our architecture figure got lost in confluence, or am I wrong?
(I'm not sure whether we had one at all at least there are dangling FIGREFs)
I don't have it anymore, could anybody take care of uploading it again?
The only thing that I have right here is the one attached...
T
Hi all,
ok, already found the cause for that specific problem :)
Greetings,
Thomas
--
View this message in context:
http://www.nabble.com/Encountered-a-problem-while-modifying-the-runtime-tp16824336p17104083.html
Sent from the Apache Ode Dev mailing list archive at Nabble.com.
14 matches
Mail list logo
