You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@oodt.apache.org by "Brian Foster (JIRA)" <ji...@apache.org> on 2012/08/06 21:05:02 UTC

[jira] [Created] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Brian Foster created OODT-484:
---------------------------------

             Summary: Enhance Workflow Lifecycle to include state change logic
                 Key: OODT-484
                 URL: https://issues.apache.org/jira/browse/OODT-484
             Project: OODT
          Issue Type: Sub-task
          Components: workflow manager
    Affects Versions: 0.4
         Environment: none
            Reporter: Brian Foster
            Assignee: Brian Foster
            Priority: Minor
             Fix For: 0.5


Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
  1) Define States XML file
  2) Define Stages XML file
  3) Mapping of States to Stages XML file
  4) Mapping of States to next valid States

I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Comment Edited] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434751#comment-13434751 ] 

Brian Foster edited comment on OODT-484 at 8/15/12 1:11 PM:
------------------------------------------------------------

ya... probably change the way default is handle a bit though... all lifecycles will be defined the same, instead of the current special way default is specified now... with some way of specifying which lifecycle should be used as default (probably a default attribute or something) if a lifecycle is not defined for a workflow... also instead of making the lifecyle file be aware of workflows, the workflows will be aware of lifecylces, that is, you will assign a workflow a lifecycle in workflows policy XML file instead of a lifecycle being given a workflow id... this will allow for shareable lifecycle files
                
      was (Author: bfoster):
    ya... probably change the way default is handle a bit though... all lifecycles will be defined the same, instead of the current special way now... with some way of specifying which lifecycle should be used as default (probably a default attribute or something) if a lifecycle is not defined for a workflow... also instead of making the lifecyle file be aware of workflows, the workflows will be aware of lifecylces, that is, you will assign a workflow a lifecycle in workflows policy XML file instead of a lifecycle being given a workflow id... this will allow for shareable lifecycle files
                  
> Enhance Workflow Lifecycle to include state change logic
> --------------------------------------------------------
>
>                 Key: OODT-484
>                 URL: https://issues.apache.org/jira/browse/OODT-484
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>    Affects Versions: 0.4
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.5
>
>
> Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
>   1) Define States XML file
>   2) Define Stages XML file
>   3) Mapping of States to Stages XML file
>   4) Mapping of States to next valid States
> I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Posted by "Sheryl John (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13432844#comment-13432844 ] 

Sheryl John commented on OODT-484:
----------------------------------

So these lifecycle XML files would have default States and Stages for a workflow that a user can reuse for every workflow, right? A user would need to only edit these files if he/she wants to add or delete states/stages or to change priorities and mappings. 
Would there be a lifecycle at workflow Id level? If yes, then I'll have to edit all lifecycle files instead of one for every workflow defined. Did I understand this right?
                
> Enhance Workflow Lifecycle to include state change logic
> --------------------------------------------------------
>
>                 Key: OODT-484
>                 URL: https://issues.apache.org/jira/browse/OODT-484
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>    Affects Versions: 0.4
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.5
>
>
> Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
>   1) Define States XML file
>   2) Define Stages XML file
>   3) Mapping of States to Stages XML file
>   4) Mapping of States to next valid States
> I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OODT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris A. Mattmann updated OODT-484:
-----------------------------------

    Issue Type: Improvement  (was: Sub-task)
        Parent:     (was: OODT-215)
    
> Enhance Workflow Lifecycle to include state change logic
> --------------------------------------------------------
>
>                 Key: OODT-484
>                 URL: https://issues.apache.org/jira/browse/OODT-484
>             Project: OODT
>          Issue Type: Improvement
>          Components: workflow manager
>    Affects Versions: 0.4
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.5
>
>
> Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
>   1) Define States XML file
>   2) Define Stages XML file
>   3) Mapping of States to Stages XML file
>   4) Mapping of States to next valid States
> I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Posted by "Sheryl John (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437260#comment-13437260 ] 

Sheryl John commented on OODT-484:
----------------------------------

Thanks for clarifying. I like that lifecycles can be shared when you have workflows being aware or able to pick lifecycles by specifying the lifecycle id. 
Also, I'm looking forward to see how you link the several lifecycle XML files. 
                
> Enhance Workflow Lifecycle to include state change logic
> --------------------------------------------------------
>
>                 Key: OODT-484
>                 URL: https://issues.apache.org/jira/browse/OODT-484
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>    Affects Versions: 0.4
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.5
>
>
> Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
>   1) Define States XML file
>   2) Define Stages XML file
>   3) Mapping of States to Stages XML file
>   4) Mapping of States to next valid States
> I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13429958#comment-13429958 ] 

Chris A. Mattmann commented on OODT-484:
----------------------------------------

Dude, YES! You totally nailed where I was taking this and where I wanted it to go!

I am super +1 on board to help you with this (or to see what you come up with along these lines).
RB away!
                
> Enhance Workflow Lifecycle to include state change logic
> --------------------------------------------------------
>
>                 Key: OODT-484
>                 URL: https://issues.apache.org/jira/browse/OODT-484
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>    Affects Versions: 0.4
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.5
>
>
> Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
>   1) Define States XML file
>   2) Define Stages XML file
>   3) Mapping of States to Stages XML file
>   4) Mapping of States to next valid States
> I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OODT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434751#comment-13434751 ] 

Brian Foster commented on OODT-484:
-----------------------------------

ya... probably change the way default is handle a bit though... all lifecycles will be defined the same, instead of the current special way now... with some way of specifying which lifecycle should be used as default (probably a default attribute or something) if a lifecycle is not defined for a workflow... also instead of making the lifecyle file be aware of workflows, the workflows will be aware of lifecylces, that is, you will assign a workflow a lifecycle in workflows policy XML file instead of a lifecycle being given a workflow id... this will allow for shareable lifecycle files
                
> Enhance Workflow Lifecycle to include state change logic
> --------------------------------------------------------
>
>                 Key: OODT-484
>                 URL: https://issues.apache.org/jira/browse/OODT-484
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>    Affects Versions: 0.4
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.5
>
>
> Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
>   1) Define States XML file
>   2) Define Stages XML file
>   3) Mapping of States to Stages XML file
>   4) Mapping of States to next valid States
> I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Updated] (OODT-484) Enhance Workflow Lifecycle to include state change logic

Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OODT-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Foster updated OODT-484:
------------------------------

    Description: 
Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
  1) Define States XML file
  2) Define Stages XML file
  3) Mapping of States to Stages XML file
  4) Mapping of States to next valid States

I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

  was:
Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
  1) Define States XML file
  2) Define Stages XML file
  3) Mapping of States to Stages XML file
  4) Mapping of States to next valid States

I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

    
> Enhance Workflow Lifecycle to include state change logic
> --------------------------------------------------------
>
>                 Key: OODT-484
>                 URL: https://issues.apache.org/jira/browse/OODT-484
>             Project: OODT
>          Issue Type: Sub-task
>          Components: workflow manager
>    Affects Versions: 0.4
>         Environment: none
>            Reporter: Brian Foster
>            Assignee: Brian Foster
>            Priority: Minor
>             Fix For: 0.5
>
>
> Let's split up the lifecycle XML file into several files (kind have it look like filemgr element and product-type XML files):
>   1) Define States XML file
>   2) Define Stages XML file
>   3) Mapping of States to Stages XML file
>   4) Mapping of States to next valid States
> I then propose we add a Priority to each Stage (its purpose will become apparent)... Then we create a new Interface: StatePreCondition... These preconditions would then be attached to a State... Then when the Workflow Processor detects a sub-processor State change it would poll each next valid State (determined by mapping in purposed XML file #4) for their PreConditions and if any of the State's PreConditions pass then that State would become the next State of that Workflow Processor (if multiple States pass as next State, then the priority attached to the Stage each State belongs to is used to determine which State becomes next State)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira