struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject RE: composable RequestProcessor
Date Thu, 05 Jun 2003 15:05:08 GMT
>At 14:44 +0100 6/5/03, PILGRIM, Peter, FM wrote:
>>This could work well. How does this processor pattern
>>solve the problem where the RequestProcessor stores
>>data member? E.g. The list of Actions recorded against
>>a ModuleConfig.

The list of actions is only really used by one process method so it doesn't 
need to be shared.


>That's a good question.  Maybe the interface for processor modules should 
>take two arguments, a "StrutsRequestContext" like what you described, which 
>would have these properties:
>That's all I can see that is handled as variables in the "process" method 
>scope.  This would be an object instantiated at the beginning of  
>"process(request,response)".  Then a second object, "StrutsModuleContext" 
>with these properties, with public accessors, only a public mutator 
>(setter) for actions:
>actions  (a mapped property)
>I guess you could just expose accessors in the RequestProcessor interface 
>for those things, but this approach insulates classes which implement the 
>interface from changes in the idea of a "StrutsModuleContext"
>  Also, by using this object, you can compromise on making those things 
>truly public because the RequestProcessor is the one who decides when to 
>pass the StrutsModuleContext in to a method call.
>This object would be created during RequestProcessor.init(servlet, 
>Joe Germuska      "If 
>nature worked that way, the universe would crash all the time." 	--Jaron 
>To unsubscribe, e-mail:
>For additional commands, e-mail:

The new MSN 8: advanced junk mail protection and 2 months FREE*

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message