struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: SAF 1.3.x and legacy RequestProcessor
Date Fri, 05 May 2006 14:22:25 GMT
At 3:03 PM +0100 5/5/06, Niall Pemberton wrote:
>On 5/5/06, Joe Germuska <> wrote:
>>  >Its probably academic, but since CRP extends RP then it seems
>>>incorrect to deprecate the whole class with a view to removing in the
>>>future. Wouldn't it be more correct to deprecate all the protected
>>>methods (e.g. processActionCreate(), processActionForm etc.)?
>>>Perhaps we should consider what the desirable end point is - IMO CRP
>>>becoming the RP seems like a good maybe the steps should be
>>>something like the following:
>>>1) Deprecate the protected methods in the RP.
>>>2) Remove RP deprecated methods and move the CRP logic into RP.
>>>Deprecate the CRP.
>>>3) Remove deprecated CRP.
>>I would agree that this is more correct.  However, deprecating CRP
>>would be annoying if people had reason to extend the
>>ComposableRequestProcessor, which for a brief while was the only way
>>to cause Struts to use a custom implementation of the ActionContext
>>interface; that specific issue has been corrected now that you can
>>instead provide an implementation class name, but there are still
>>some potential bootstrapping issues if you wanted to have your custom
>>ActionContext class be initialized in some special way before it was
>>launched on its path down the chain.
>I take your point about removing CRP being annoying - although it
>doesn't seem a great burden for people to have to change their custom
>RP's ancestor from CRP to RP - since I assume that people don't have
>lots of custom RPs.

I agree in general with your assumption; I'm actually just trying to 
get some other folks to look at the code I wrote around that and help 
make sure that we don't end up forcing people to make lots of custom 
RPs because of an oversight.  I've never been all that satisfied with 
the ActionContext creation/bootstrap process in CRP.  It works, but 
it seems kind of clumsy.

>For me the ideal end point is just a single RP and it seems cleaner to
>have it called RP than CRP. That would be my preference, but if others
>disagree and think that getting there is a PITA - its not a big deal.

no, I agree with you.


Joe Germuska *    

"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed.  Try something new."
	-- Robert Moog

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

View raw message