Re: Re: Re: [OSWF] Status of JIRA WF-198?
"Nick Dellamaggiore" <[email protected]> Sun, 19 Oct 2003 15:20:43 -0700
| Newsgroups | gmane.comp.java.open-symphony.devel |
|---|---|
| Message-ID | <[email protected]> |
Hani, I'm pretty sure all the diffs I attached to WF-225 are compared to the latest revisions in HEAD. I changed WorkflowDescriptor, StepDescriptor, ValidationTestCase, the DTD and added 2 sample wf dtds. I did a compare with latest from HEAD and the versions haven't changed since I checked them out. When JIRA comes back up, I'll make sure. -nick "Nick Dellamaggiore" <[email protected]> wrote in message news:[email protected]... > 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 ------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com