Update JsfView so that state saving no longer occurs during
processUserEvent(). This is required to ensure that Mojarra's
StateContext.release(...) method is not called too early.
Prior to Mojarra 2.1.16 multiple calls to saveView had no side effects,
but the fix to JAVASERVERFACES-2609 changed this behavior.
In order to retain the fix for SWF-1577 the saveState() method is now
called from getUserEventState(). This should ensure that the
StateContext$AddRemoveListerner is still removed, even when WebFlow
bypasses the usual state saving for certain flow redirects.
Issue: SWF-1631
The build now compiles with Servlet API 3.0 and JPA 2.0 both of which
are required with Spring Framework 4.0. However there are no hard
dependencies in Web Flow on either.
Issue: SWF-1600
The master branch has been using Gradle for a while. The expectation
at the time was that minor maintenance releases can be done on 2.3.x
with the existing Ant build. However that is no longer possible to
perform a release and we need to perform a 2.3.3 release.
The change mirrors similar changes on the master branch:
4e81930b7250a1cf1def
Issue: SWF-1615
Change JsfView.userEventQueued() to check for 'javax.faces.ViewState'
via the FacesContext rather than the RequestContext. This allows
potential multi-part request submissions to be processed by JSF rather
than Spring.
Issue: SWF-1482
Recent updates to Mojarra added a SKIP_ITERATION hint when delivering
the PostRestoreStateEvent. Web Flow should follow the same logic.
Issue: SWF-1549
Backport-Commit: cd3d8be819
Previously we checked the "Faces-Request" header only.
Now we try to delegate the call to
PartialViewContext.isAjaxRequest() first. If a FacesContext
is unavailble for some reason we also check the
"javax.faces.partial.ajax" request parameter.
A PostRestoreStateEvent should be delivered whenever a JSF view is
restored. Typically we rely on JSF to generate required events but
in this case since WebFlow handles the RESTORE_VIEW phase itself,
we need to deliver this event ourselves.
Issues: SWF-1500
For JSF 2.0.x Spring Web Flow the view root could not be preserved
across redirects in the same state (e.g. following validation)
because a JSF state saving listener held on to the FacesContext,
which Web Flow releases before the redirect.
This issue was addressed in JSF 2.1
http://java.net/jira/browse/JAVASERVERFACES-1604
which means we can allow the view root to survive the redirect.
Note that the behavior can also be controlled with the
redirect-in-same state flow execution attribute.
Issues: SWF-1502
The "embedded" mode flag, which is used to suppress redirects so
that a flow can be embedded on a surrounding page, was previously
stored as a flow execution attribute. The idea was that a flow can
be launched in embedded mode simply by passing a flow input rather
than having that decision fixed through a static flow definition.
However flow execution attributes are not a suitable place to store
the embedded mode flag since they are globally shared. Instead this
information is now stored a flow session attribute, which means that
each individual session (including subflows) can have be in embedded
mode or not without affecting others
Previously Web Flow's BindingResult implementation distinguished
object from field-level errors by checking if the source of the
error is null or otherwise a String. However, class-level bean
validation errors have a field source represented by an empty
String. After this change object and field-level errors are
recognized by checking for String-based field source that is
neither null nor empty.
This commit also contains a fix for spring-faces tests where
in JSF 2.1 the presence of an unreleased FacesContext may
cause some tests to fail.
Previously isValidationFailed() merely delegated to the wrapped
FacesContext ignoring any errors that may have been added to
Web Flow's MessageContext. After the change isValidationFailed()
checks and returns true if the MessageContext contains errors
or otherwise it delegates.
Issues: SWF-1490
