The PageFlowRequestProcessor.processMapping() is not handling a default
"unknown" action defined in the GlobalApp
-----------------------------------------------------------------------------------------------------------------
Key: BEEHIVE-1037
URL: http://issues.apache.org/jira/browse/BEEHIVE-1037
Project: Beehive
Type: Bug
Components: NetUI
Versions: 1.1
Reporter: Carlin Rogers
Assigned to: Carlin Rogers
Fix For: 1.1
It seems that with svn revision 351812 (for
http://issues.apache.org/jira/browse/BEEHIVE-1017 ) and svn revision 356056
(for http://issues.apache.org/jira/browse/BEEHIVE-1024 ), the behavior of
PageFlowRequestProcessor.processMapping() has changed.
The scenario that I'm investigating is for a portal that uses
PageFlowUtils.strutsLookup().
- A (deprecated) Global.app is included in the NetUI web app.
- The Global.app has a struts merge with a struts module config file.
- The struts module config file includes an action that has the "unknown"
attribute (a sort of default action).
- The "unknown" action in the merged struts module config file is actually an
action implemented in the Global.app.
Then a portlet renders a page flow that has a page with a link to a bogus
action. Prior to the two revisions above, when the request is made to the bogus
action, processMapping() calls doForward() to the Global.app URI and returns a
null map. Then, strutsLookup() checks that a redirect did not occur and tries
recursive strutsLookup() on the return URI (the global.app). In this second
pass to processMapping() we find the action that is defined by the "unknown"
attribute that is then called to handle the bogus action.
Now, with the revisions above, there are two things I've noticed.
1) First, when the initial page flow with the bogus action is rendered, the
module config of the Global.app is not added to the servlet context as it was
in the past. With svn revision 351812, the FlowController.reinitialize() method
(called during a create()) no longer calls the initModuleConfig() method and in
turn ensures that the Struts module for the given path is registered as an
attribute of the servlet context. When processMapping() gets the bogus action,
the check to see if a global app module config even exists fails. The call to
InternalUtils.getModuleConfig() for the GlobalApp module config will be null.
We will fail and fall into a call to processUnresolvedAction().
2) Even if the Global.app module config was available from the context, I think
there is still a second issue. In svn revision 356056, processMapping() now
checks that there is a module config for the Global.app and checks that it has
the desired action before falling into processUnresolvedAction(). However, we
don't check to see if Global.app has a default "unknown" action to handle a
bogus action.
I will try to attach a MockPortal app to repro this. As pointed out to me, some
sort of API testing might be a better bet to catch something like this.
Something to do for next rev of NetUI.
--
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
