[api] Why do SlingHttpServlet*Wrappers wrap Sling objects, not javax.Servlet ones?

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

Looking at the current sling-api:

public SlingHttpServletRequestWrapper(SlingHttpServletRequest delegatee)
I would have expected

public SlingHttpServletRequestWrapper(ServletRequest delegatee)

And then the constructor can complain if the delegatee (why not call
that simply "wrappedRequest" by the way?) is not of the right type.

And the same goes for the response wrapper, of course.

What's the rationale for doing things the current way? I'm not against
that, just trying to understand the pros and cons.

-Bertrand

Re: [api] Why do SlingHttpServlet*Wrappers wrap Sling objects, not javax.Servlet ones?

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Montag, den 29.10.2007, 11:19 +0200 schrieb Bertrand Delacretaz:
> public SlingHttpServletRequestWrapper(SlingHttpServletRequest delegatee)
> I would have expected
> 
> public SlingHttpServletRequestWrapper(ServletRequest delegatee)

This is just inline with the Servlet API HttpServletRequestWrapper,
which takes a HttpServletRequest. In addition, I would want the user of
the wrapper to know what (s)he does explicitly by declaring the
constructor according to its expectations and not having to ressort to
some JavaDoc codifying something which may be codified (better) by the
signature.

> ... the delegatee (why not call that simply "wrappedRequest" by the way?) ...

Well, I always use the name delegatee when implementing wrappers. But
wrappedRequest is equally fine and the HttpServletRequestWrapper simply
calls the parameter "request". I have no strong bias, probably
wrappedRequest is better than delegatee.

Regards
Felix