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

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

I actually ended up using a special <common-action id="2" /> tag to denote
common-action references under the <actions> tag (required DTD
modifications...Hope that's ok).  Also added a JUnit to make sure I didn't
hose anything.  I ended up having to change 2 classes in the loader package
along with the DTD.  What is the recommended patching strategy? Should I
send you diffs of all the files?

Also, I've finally come to closure regarding the original problem I was
trying to solve (WF-198).  After stepping through AbstractWorkflow, I
realized that there is really no easy fix.  I basically need to 'cancel' a
split state and have it forcefully resolve into a single step without a
join.  The way the join code works is that it requires n-1 steps in the
split state to be markedFinished before it can resolve the join (it only
marks the nth step finished).  In the end, I decided not to hack up
AbstractWorkflow just to solve my special case. Instead, I added a hack to
my own code like so:

public void forceJoin( /* params */ ) {
...
   if( currentSteps.size() > 1 ) {  // in split state => move n-1 steps to
history
      for( int i = 0; i < currentSteps.size() - 1; i++ ) {
        Step currStep = (Step)currentSteps.get( i ) ;
         if( currStep.getFinishDate() == null ) {
            workflowStore.markFinished( currStep /* ... */ ) ;
         }
         workflowStore.moveToHistory( currStep ) ;
      }
   }
   // now, let OSWorkflow finish the transition off
   wf.doAction( wfId, actionId, null ) ;  // not in split => let OSWorkflow
handle it
}

ugly, but it works. You can cancel WF-198.

-nick

"Hani Suleiman" <[email protected]> wrote in message
news:[email protected]...
> 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





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