Rob, This utility will be very useful.
In the restlet, form data is treated separately. Will the form data be part of the peudo HttpServletRequest? Jennifer On Wed, Jun 4, 2008 at 11:36 AM, Rob Heittman <[EMAIL PROTECTED]> wrote: > > I think we need an RFE on that utility, and it should be a standard part of > the Servlet extension. The fact that there are a couple of messy and or > labor intensive ways to do it won't satisfy the large development community > that is VERY COMMITTED to the Servlet API. I am thinking of folks like the > IBM Websphere and/or BEA community that have made a very strong commitment > to their J2EE application server environment and tend to express all their > APIs in terms of the Servlet API specifically. The idiom > doSomething(HttpServletRequest request, HttpServletResponse response) is > canon -- following the Uniform interface using the tools at hand. > For those of us working in a broad device panorama that encompasses > embedded, standalone, OSGi, Servlet, and even cross-compiled (GWT) cases, > the idea of having to touch, say, an HttpServletRequest directly is just > sort of an annoyance associated with one of many deployment options. For > others, tight Servlet API integration is a core part of the value > proposition. > > The possibility that the relevant Servlet API objects are reachable through > contortions is not enough; it must be straightforward, easy, and > supportable. So I'd like to see something like a ServletAPI utility class > with > > /** @deprecated */ > public static HttpServletRequest getHttpServletRequest(Request request); > /** @deprecated */ > public static HttpServletResponse getHttpServletResponse(Response > response); > public static HttpServletRequest createHttpServletRequest(Request > request); > public static HttpServletResponse createHttpServletResponse(Response > response); > > The first two methods would return the original and actual objects > associated with the call, if they exist, or null if the call did not > originate with a Servlet connector. I would deprecate these because they > are almost certainly a bad idea to use for any non-trivial purpose -- due to > the likelihood of conflict between direct mutation and Restlet API > operations. > > The last two methods would return a Restlet emulation wrapper object that > conforms to the HttpServletRequest and HttpServletResponse API, but > transforms the underlying methods into Restlet operations. Obviously there > would need to be some limitations to this, especially at first -- I can > foresee a number of places where emulation is non-trivial. But it would > seem easier and more supportable to expand and improve the behavior of such > wrappers over time if demand drives it, than to ask every Servlet developer > to implement and support their own independent workarounds. And I do > believe that most of the time HttpServletRequest and HttpServletResponse are > just passed in APIs for convenience -- all the calling code really needs to > access is something trivial like a cookie setting, header, or request > parameter. All easy to emulate. > > This approach also has practical value for us "many container" developers, > because it would allow us to take certain existing APIs that are tightly > bound to the Servlet API, and integrate them in non Servlet container > environments by just supplying the servlet-api.jar and the Servlet > extension. > > Want to beat up on this idea before I type in an RFE? > > - R > > On Wed, Jun 4, 2008 at 10:55 AM, Bruno Harbulot < > [EMAIL PROTECTED]> wrote: > >> I am not sure how restlets can be useful if it cannot integrate with >>> legacy or existing systems. >>> >> >> >> If you're given some library which has an API of the form >> "authenticate(HttpServletRequest servletRequest)", then I think what Rob >> suggested in reply to your message is probably the cleanest solution: >> creating a "fake" HttpServletRequest, populated with the relevant >> information from the Restlet Request. >> Perhaps there could be some utility class to do this conversion. Feel free >> to contribute the code if you implement it... >> >> >> Best wishes, >> >> Bruno. >> >> >
