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