1.4 -> 2.0 migration issues with SafeRequest/Response

Due to release and testing cycles, I am using the latest stable release as
of a couple weeks ago, which is 1.4.  Even if the 2.0 changes are
backported, that doesn’t solve the problem of timelines or the removal of
classes.  The issue here is breaking existing implementations.  Kevin made
the following suggestion for 2.0 which makes some sense

In the case of SafeRequest and SafeResponse if it's simply a case of them
being renamed to SecurityWrapperRequest and SecurityWrapperResponse
respectively we can just do something like this:

                /** Old class name for {@code SecurityWrapperRequest}.
                 * @see SecurityWrapperRequest
                 * @deprecated This class will be removed in release 2.1.
             *             Use {@code SecurityWrapperRequest} instead.
                 */

                public class SafeRequest extends SecurityWrapperRequest {
                  ... declare / implement whatever public CTORs you
previously had ...
                }

and ditto for SafeResponse. Then people's old code should still work. Come
release 2.1 (or 3.0 or whatever), remove this.

Original issue reported on code.google.com by manico.james@gmail.com on 5 Nov 2009 at 10:47

andytanoko / owasp-esapi-java

1.4 -> 2.0 migration issues with SafeRequest/Response #47