Re: Re: Re: [OSWF] Status of JIRA WF-198?
Hani Suleiman <[email protected]> Mon, 13 Oct 2003 10:54:37 -0400
| Newsgroups | gmane.comp.java.open-symphony.devel |
|---|---|
| Message-ID | <[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