Re: Re: [OSWF] Status of JIRA WF-198?

Yeah, +1 to this from me, so I'll be accepting any patches for it!

One thing to note though, is that instead of an implicit 'if no body 
then look in common-actions' I'd say something like:

<action id="2" refid="0" /> would be more explicit and clearer.

On Saturday, October 11, 2003, at 07:50 AM, Eric Pugh wrote:

> I have to say, one of the things that attracted me to OSWF was the
> simplicity..  And I think that what Nick is proposing is simpler 
> because it
> removes the concept of local versus global actions, and provides a more
> compact way of referencing a action over and over.   Also, while what 
> he is
> proposing is to solve using the same action over and over, if you have 
> an
> action used 3 times, this is a much compactor, simpler way to describe 
> that
> as well.
>
> If we change it, lets definitly make sure that the global-actions 
> syntax is
> clearly highlighted as deprecated.
>
> Eric
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]]On
>>  Behalf Of
>> Nick Dellamaggiore
>> Sent: Friday, October 10, 2003 8:47 PM
>> To: [email protected]
>> Subject: [Opensymphony-developers] Re: [OSWF] Status of JIRA WF-198?
>>
>>
>> Ok. Before I patch, I want to know how global-actions play
>> into the new
>> "workflow state" semantics of v2.6.  Here is the section that
>> worries me:
>>
>> " If the caller does not explicitly alters the instance
>> state, the workflow
>> will remain in this state until it is unambigiously completed. This is
>> defined to be the case when the workflow cannot possibly
>> perform any further
>> actions. In this case, the workflow will automatically move
>> to the COMPLETED
>> state. "
>>
>> So, once we reach an action with no 'local actions'
>> available, the workflow
>> is marked completed. Thus, no further actions can be
>> performed due to the
>> following code in doAction():
>>
>> if( entry.getState() != WorkflowEntry.ACTIVATED ) {
>>    return;
>> }
>>
>> So, the notion of global actions doesn't apply here.  There
>> ARE potential
>> (global) actions to be fired, but the workflow state
>> disallows it since
>> there are no local actions left for the current step. Fair enough.
>>
>> Actually, in a true finite state machine, each state has a
>> set of actions
>> (as you've correctly modelled). There is no notion of a
>> 'global-action'.
>> Should we just do away with this feature entirely (in a
>> future release)?
>> That would be fine by me as long as there was a feature in
>> the XML file
>> allowing me to refactor a common (not global) action out that
>> can then be
>> compactly referenced by id in each step it can be used.  At
>> runtime, it
>> would simply appear as another ActionDescriptor for the Step.  The XML
>> notation below would just be shorthand (macro) for writing
>> the action out
>> over and over again:
>>
>> <workflow>
>>
>>    <common-actions>
>>       <action id="99" name="Cancel Review">
>>          <pre-functions>
>>             <!-- ... -->
>>          </pre-functions>
>>          <results>
>>             <unconditional-result old-status   = "Interrupted"
>>                                   status       = "Cancelled"
>>                                   step         = "100"
>>                                   owner        = "${caller}" >
>>         <post-functions>
>>            <!-- lots of post function definitions I don't
>> want to have to
>> copy/paste into each action below -->
>>         </post-functions>
>>        </unconditional-result>
>>          </results>
>>       </action>
>>    </common-actions>
>>
>>     <step id="10" name="Initial Review"
>>             <action id="101" name="Complete Review">
>>                <!-- regular action xml goes here -->
>>             </action>
>>
>>            <!-- Workflow Loader code will resolve this action from
>> common-actions above since the action body is missing -->
>>            <action id="99" />
>>
>>           <!-- OR give it a special tag to aid in
>> parsability/readability -->
>>           <common-action id="99" />
>>       </step>
>> </workflow>
>>
>>
>> I can write the code for this.  I'd leave the current global-action
>> semantics intact to allow backward-compatibility and just
>> change the Loader
>> so it recognized the new shorthard notation.  What do you think?
>>
>> -nick
>>
>>
>> "Hani Suleiman" <[email protected]> wrote in message
>> news:[email protected]...
>>> Please do provide a patch, the splits/join stuff is rather
>> murky for me
>>> and I'd rather someone who is actively using it provide
>> patches than be
>>> guessing what it's supposed to be doing.
>>>
>>> On Wednesday, October 8, 2003, at 08:58 PM, Nicholas J.
>> Dellamaggiore
>>> wrote:
>>>
>>>> I posted a JIRA about 2 months ago regarding a pretty serious
>>>> OSWorkflow corruption issue.  In a nutshell, if you're in a split
>>>> state (i.e 2 current steps are active) and you fire a
>> global action
>>>> before the split is resolved, the global action creates
>> its new step
>>>> and leaves the splits steps alive, thus resulting in THREE current
>>>> steps.  The offending code is in AbstractWorkflow
>> (actually, I think
>>>> all non-getter/setter OSWF code lives here) and I detailed the
>>>> potentially buggy areas in the JIRA.  I noticed that the
>> JIRA hasn't
>>>> been placed into the 2.6 release.  Were you planning to
>> fix it for the
>>>> upcoming release? If not, I plan to just go ahead and
>> patch it myself.
>>>>  Thanks.
>>>>
>>>> http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WF-198
>>>>
>>>> -nick
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.net email is sponsored by: SF.net Giveback Program.
>>>> SourceForge.net hosts over 70,000 Open Source Projects.
>>>> See the people who have HELPED US provide better services:
>>>> Click here: http://sourceforge.net/supporters.php
>>>> _______________________________________________
>>>> Opensymphony-developers mailing list
>>>> [email protected]
>>>>
>> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.net email is sponsored by: SF.net Giveback Program.
>>> SourceForge.net hosts over 70,000 Open Source Projects.
>>> See the people who have HELPED US provide better services:
>>> Click here: http://sourceforge.net/supporters.php
>>
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> SourceForge.net hosts over 70,000 Open Source Projects.
>> See the people who have HELPED US provide better services:
>> Click here: http://sourceforge.net/supporters.php
>> _______________________________________________
>> Opensymphony-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Opensymphony-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-developers
>



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php