[ http://issues.apache.org/jira/browse/BEEHIVE-1037?page=all ] Alejandro Ramirez closed BEEHIVE-1037: --------------------------------------
Verifed fixed with build synched to svn revision 368440 Executed the repro steps and now the bogusAction is handled correctly by the merged "noMatch" action in the Global.app. > 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 > Assignee: Alejandro Ramirez > Fix For: 1.1 > Attachments: j1037-repro.zip > > 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
