struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jouravlev" <>
Subject Re: SAF 1.3.x and legacy RequestProcessor
Date Fri, 05 May 2006 16:35:50 GMT
> From: Niall Pemberton <>
> Date: May 5, 2006 2:36 PM
> Subject: Re: SAF 1.3.x and legacy RequestProcessor
> 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.

Niall, do you suggest to have (1) in first release of 1.3, (2) in the
next release, and (3) yet another release? Because if the whole change
is implemented at once, why deprecating methods/classes before they
are removed? No one would have a chance to see them deprecated :-)

I understand that the step-by-step process makes sense primarily to
warn/inform users that a certain feature will be removed. But 1.3 has
not been released yet, so all steps can be done at once, cannot they?

> 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.

Yes, I agree, having one rp called RP seems better to me.

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

View raw message