SWF tidbit

[Cantor, Scott]

Not surprisingly, SWF has some definitely strange behavior when it comes
to event handling but I'm getting my mind around it, and I think it will
work, we just have to be careful with the error handling. But that was
already a bit brittle to begin with, so I think the advantage of
eliminating two dozen stack frames per request is still worth it.

The below basically works. If any actions return events (errors), the
global rule fires, otherwise it just keeps running steps until something
returns a value that matches the non-global rule. So "proceed" becomes
just a flow definition convention, not an Event.

<action-state id="DecodeMessage">
	<evaluate expression="DecodeMessage" />

	<evaluate expression="CheckMessageVersion" />
	<evaluate expression="SAMLProtocolAndRole" />
	<evaluate expression="SAMLMetadataLookup" />

	<evaluate expression="InitializeRelyingPartyContexFromSAMLPeer" />
	<evaluate expression="SelectRelyingPartyConfiguration" />
	<evaluate expression="SelectProfileConfiguration" />

	<evaluate expression="PopulateSignatureValidationParameters" />
	<evaluate expression="'proceed'" />
        
	<transition on="proceed" to="CheckForInboundSubflow" />
    </action-state>



<global-transitions>
	<transition on="#{!'proceed'.equals(currentEvent.id)}"
		to="SavePreviousEventAsError" />
    </global-transitions>

When the transition rules become more complex, it makes sense to group
things into separate action-states, but when it's just one evaluate after
another, this works fine.

The code changes here were as I said pretty much nothing, just commenting
out a few lines that were returning "proceed" as an Event (apart from
changing javadocs). The tests all still work by making an assert of
"proceed" match a null Event, though of course that could be cleaned up
later.



I may be able to improve the code that's moving Events around in the
context tree once I have more done, not sure yet. But I think this is a
definite improvement.

-- Scott