PageFlowUtils.removeLongLivedPageFlow() from another page flow, fails to run
the destroy() page flow life cycle method
----------------------------------------------------------------------------------------------------------------------
Key: BEEHIVE-1103
URL: http://issues.apache.org/jira/browse/BEEHIVE-1103
Project: Beehive
Type: Bug
Components: NetUI
Versions: V1, 1.0.1
Reporter: Carlin Rogers
Programmatically trying to remove a long lived page flow by calling
PageFlowUtils.removeLongLivedPageFlow() from another page flow, fails to run
the destroy() page flow life cycle method, though the long lived page flow does
get removed from the session.
The destroy() method is not called because the long lived page flow attribute
name does not exist on the request (just on the session) when
DeferredSessionStorageHandler.removeAttribute() is called from the
PageFlowUtils routine. Therefor it will not "Emulate a removeAttribute on the
session" and call the long lived page flow's valueUnbound() method. However,
DSSH.removeAttribute() does add this attribute to the change attribute list.
Then at when DSSH.applyChanges() gets called we do remove the the attribute
abject from the session but without the PageFlowManagedObject.valueUnbound()
method calling the destroy().
Note that when the PageFlowUtils.removeLongLivedPageFlow() is called via the
long lived page flow's own remove() routine (inherited from
FlowController.remove()), then the attribute name is on the request (as well as
the session) and the destroy method gets called. However, a page flow that
calls its remove() method from within one of its actions may have undesirable
side effects or throw exceptions if the page flow has a @Control control. The
remove() method runs through the page flow destroy() life cycle method before
the ControlContainerContext endContrext() method and any onRelease() calls to
the control.
This is probably not a scenario that is performed very often but was noted from
some tests of long lived page flows that contain controls. I'll submit these
tests shortly.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
