---------- Forwarded message ---------- From: Niall Pemberton <[EMAIL PROTECTED]> Date: May 5, 2006 2:36 PM Subject: Re: SAF 1.3.x and legacy RequestProcessor To: Joe Germuska <[EMAIL PROTECTED]>
On 5/5/06, Joe Germuska <[EMAIL PROTECTED]> 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 idea...so 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'm an avid user of custom ActionContext implementations to provide typesafe control of key application objects stored as request and session attributes (i.e. context.getAuthenticatedUser(), etc). I have not needed any special initialization, and I suspect that you could achieve that kind of stuff in a command at the beginning of your chain, since the RequestProcessor doesn't have references to anything that isn't also in the ActionContext. Still, it might be worth a few other sets of eyes looking at how that works. For actual request processing, it seems clear that all those protected methods are superceded by commands; it's just the set-up (and possibly teardown?) that are still new enough that it's hard to know.
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. Niall
Joe
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
