Carsten Ziegeler skrev:
Grzegorz Kossakowski wrote:
After exploring code for a while I came to conclusion that I need to
implement stub implementation of HttpServletRequest, HttpServletResponse
and ServletContext that will forward to Cocoon's corresponding classes.
Hmm, or the other way round - if the tests would create httpservlet
classes first, perhaps the current cocoon environment wrappers could
just be used to wrap them.
Additionally, I've read /[RT] Ditching the environment abstraction/
thread[1] where Daniel proposed to switch to standard servlet interfaces
from Cocoon's own ones. I've seen that several folks were rather
reluctant[2][3] to allow these changes. There were concerns raised[4]
that some methods in our interfaces has no counterparts in Servlet API
interfaces.
Since ProcessInfoProvider operates on interfaces from Servlet API I
wonder if community's standpoint changed to date.
Carsten, it was you who introduced ProcessInfoProvider interface, could
you comment?
It's a long time ago....well, the basic idea was that, as Daniel pointed
out in the mentioned thread, there are a lot of libraries/code out there
which require servlet classes (req/resp/context) are required.
The ProcessInfoProvider is a bean which just delivers these and does
internally the required wrapping or unwrapping. In addition this creates
a migration path as new stuff can be written which depends just on the
servlet api and the bridge to the old stuff is this info provider.
I totally agree that we should remove our own environment as soon as
possible, but this would create a lot of incompatibilities (as outlined
in one of those threads).
"A lot of incompatibilities" is an exaggeration. If we just let or
Request, Response, Session and Cookie extend the corresponding http
servlet ones, we would just get a few minor incompatibilities that IMO
would be rather minor in comparison with the benefits of using a
standardized API.
The biggest is that req.getSession() returns a
o.a.c.e.Session currently and with switching to the servlet api it
becomes a httpsession.
As o.a.c.e.Session in the above proposal would extend HttpSession an
object implementing o.a.c.e.Session can still be returned, so it
shouldn't be such a big deal.
I took a more detailed look at it, we would need to change the following
methods in Request:
Cookie[] getCookies();
InputStream getInputStream();
Session getSession(boolean create);
Session getSession();
I discussed the session methods above. The o.a.c.e.Cookie is a little
bit worse as it is an interface and javax.servlet.http.Cookie is a
class. But we could let o.a.c.e.http.HttpCookie (which is the only
implementation of o.a.c.e.Cookie) extend javax.servlet.http.Cookie and
just remove o.a.c.e.Cookie (which has exactly the same signature as
javax.servlet.http.Cookie). The getInputStream method needs to return a
ServletInputStream instead of an InputStream. As the
o.a.c.e.http.HttpRequest.getInputStream returns a ServletInputStream
anyway, I don't think it would lead to any problems.
Response and Session lacks a few methods from their http servlet counter
parts. We could let them throw unsupported operation exceptions.
So to summarize, it would be a great benefit to let our environment
abstractions extend the http servlet ones and the cost would be low. So
it is time to do it.
/Daniel
