Return-Path: X-Original-To: apmail-oodt-commits-archive@www.apache.org Delivered-To: apmail-oodt-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 41266CC19 for ; Wed, 15 Aug 2012 02:12:39 +0000 (UTC) Received: (qmail 3244 invoked by uid 500); 15 Aug 2012 02:12:39 -0000 Delivered-To: apmail-oodt-commits-archive@oodt.apache.org Received: (qmail 3143 invoked by uid 500); 15 Aug 2012 02:12:38 -0000 Mailing-List: contact commits-help@oodt.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@oodt.apache.org Delivered-To: mailing list commits@oodt.apache.org Received: (qmail 3069 invoked by uid 99); 15 Aug 2012 02:12:38 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 02:12:38 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 185332C5BE8 for ; Wed, 15 Aug 2012 02:12:38 +0000 (UTC) Date: Wed, 15 Aug 2012 13:12:38 +1100 (NCT) From: "Brian Foster (JIRA)" To: commits@oodt.apache.org Message-ID: <549659954.11274.1344996758100.JavaMail.jiratomcat@arcas> In-Reply-To: <239112740.17869.1344279903331.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Comment Edited] (OODT-484) Enhance Workflow Lifecycle to include state change logic MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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