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

Ok. I attached all my files to a new JIRA (WF-225).  I accidentally attached
2 workflow.dtd files. They are both the same. I also attach 2
ValidationTestCase.java files. Use the 2nd one.  The code changes were
pretty straightforward and hopefully shouldn't hose anything.

-nick


"Hani Suleiman" <[email protected]> wrote in message
news:[email protected]...
> Patches are best attached to jira issues, so we can make sure they're
> tracked properly etc.
>
> On Monday, October 13, 2003, at 03:03 AM, Nick Dellamaggiore wrote:
>
> >> <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
> > _______________________________________________
> > 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