beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers (JIRA)" <>
Subject [jira] Resolved: (BEEHIVE-1037) The PageFlowRequestProcessor.processMapping() is not handling a default "unknown" action defined in the GlobalApp
Date Tue, 10 Jan 2006 20:31:21 GMT
     [ ]
Carlin Rogers resolved BEEHIVE-1037:

    Resolution: Fixed
     Assign To: Alejandro Ramirez  (was: Carlin Rogers)

Fixed with revision 367778.

The test case for the repro that is attached to this issue can be used to test this fix. With
the fix, the link on the bogus action should successfully go to the GlobalApp's /noMatch action
defined as "unknown". This forwards to strutsMerge/test1/done.jsp.

> The PageFlowRequestProcessor.processMapping() is not handling a default "unknown" action
defined in the GlobalApp
> -----------------------------------------------------------------------------------------------------------------
>          Key: BEEHIVE-1037
>          URL:
>      Project: Beehive
>         Type: Bug
>   Components: NetUI
>     Versions: 1.1
>     Reporter: Carlin Rogers
>     Assignee: Alejandro Ramirez
>      Fix For: 1.1
>  Attachments:
> It seems that with svn revision 351812 (for
) and svn revision 356056 (for ), the behavior
of PageFlowRequestProcessor.processMapping() has changed.
> The scenario that I'm investigating is for a portal that uses PageFlowUtils.strutsLookup().
> - A (deprecated) is included in the NetUI web app.
> - The 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
> 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 URI and returns a null map. Then, strutsLookup() checks
that a redirect did not occur and tries recursive strutsLookup() on the return URI (the
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 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 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 and checks that it has the desired action before falling
into processUnresolvedAction(). However, we don't check to see if 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:
For more information on JIRA, see:

View raw message