beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <richf...@privatei.com>
Subject Re: Question about BEEHIVE-1024
Date Mon, 09 Jan 2006 07:27:22 GMT
Hey Carlin,

Sorry for the delay.  I agree that we should be checking for an 
"unknown" action mapping in the global app module, so if you're 
suggesting making that change, I agree.

My answer to the rest is a little more involved:

    - There's already a rough mechanism for avoiding direct response 
output.  In InternalUtils, there's avoidDirectResponseOutput().  If 
that's called on the request, then InternalUtils.sendError() will throw 
an exception instead of writing to the response.  This is what I think 
should be happening here -- we should be calling sendError().

    - I think that two things should probably change here: 1) 
InternalUtils.avoidDirectResponseOutput() should be replaced with a flag 
in PageFlowRequestWrapper, and 2) strutsLookup() should just set this 
flag off the bat.  We shouldn't be writing to the response *ever* during 
strutsLookup().

Let me know what you think (and if you have any questions about this).

Rich

Carlin Rogers wrote:

>Just wanted to note that the difference in the behavior is also related to a
>struts merge  where the struts module config has an action defined with the
>"unknown" attribute (making it like a default). I think the missing
>condition is that we check to see if the GlobalApp has the action config but
>we don't check any of the action configs on the global app to see if they're
>"unknown".
>
>So, If the global app includes a Struts Merge and that struts module config
>includes an unknown action, we'll never hit it.
>
>Carlin
>
>On 1/5/06, Carlin Rogers <carlin.rogers@gmail.com> wrote:
>  
>
>>Hey Rich,
>>
>>Hope your work is going well!
>>
>>I have a question about svn revision 356056 ( http://svn.apache.org/viewcvs.cgi?rev=356056&view=rev
>>) checked in as a fix for BEEHIVE-1024. It seems that it changed the
>>behavior of PageFlowRequestProcessor.processMapping() and how we handle an
>>unknown action. With this change, the code path for an unknown action in
>>processMapping() fails the new check to see if it is in the globalApp
>>(...globalApp.findActionConfig(path) != null). We drop to the else statement
>>and into a call to processUnresolvedAction() which uses the
>>DefaultExceptionsHandler class and eventually writes out the HTML of our
>>action not found error message directly to the response. I think this looks
>>OK. However, having the error message written to the response may not be the
>>desired behavior for something like a portal using a call to
>>PageFlowUtils.strutsLookup(). What do you think?
>>
>>If we leave the fix as is, could we use the
>>PageFlowRequestWrapper.isScopedLookup() condition to determine if this is
>>from strutsLookup() or not before calling processUnresolvedAction(). I.E.
>>do something different for an unknown action in a strutsLookup()? Just
>>curious.
>>
>>Thanks,
>>Carlin
>>
>>    
>>
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message