Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: Release 1.5.1
-
Fix Version/s: Release 1.5.2, Release 1.6
-
Component/s: None
-
Labels:None
Description
When a forward is done to an ActionBean class that has already been instantiated, setContext(..) is not necessarily called for the new ActionBeanContext, by design. In cases where the new context is not passed to the ActionBean, the context retains old information, such as event name, that can lead to some baffling issues. The relevant information should be passed to the existing context in such cases.
This is related to
STS-565. The root of the problem is that we often end up with the ExecutionContext and ActionBean using two different ActionBeanContext instances in the same request. To fix that, DispatcherHelper, after resolving the ActionBean for the request, will then check to see if the bean's context instance is different from the one in the ExecutionContext. If so, then it will take the bean's context, copy the event name from the ExecutionContext to it (normally null) and then pass it to ExecutionContext.setActionBeanContext().STS-565. The root of the problem is that we often end up with the ExecutionContext and ActionBean using two different ActionBeanContext instances in the same request. To fix that, DispatcherHelper, after resolving the ActionBean for the request, will then check to see if the bean's context instance is different from the one in the ExecutionContext. If so, then it will take the bean's context, copy the event name from the ExecutionContext to it (normally null) and then pass it to ExecutionContext.setActionBeanContext().