>The distinction is quite simple. Use HTTP context for objects that >represent session data and can be mutable in the course of the request >processing. HTTP context is somewhat similar to the attribute collection >of ServletRequest. Use HTTP parameters for simple objects that define >behavior of the components and are immutable. The closest Servlet >equivalent I can think of is ServletContext / ServletConfig.
This was very helpful - thanks. I'm now recalling that the documentation calls out this role for HTTP Context. Your reply re/ ServletContext/Config tells me that the stuff I had planned on gleaning from the ServletContext should go in the params, as I was originally inclined. For the access of these params, I'm using the same idiom as core, which is to define a IFooPname interface for hanging the map keys off of, and a FooParam class with a bunch of static convenience methods for accessing those params. I had planned on deriving from HttpProtocolParams, but didn't go there because it's final, and because I'm not sure that's a cohesive binding anyway. Thanks! If you do put together a reverse proxy tutorial, I'll be sure to read it, and structure my approach along its lines. -- Todd From: Oleg Kalnichevski <[email protected]> To: HttpClient User Discussion <[email protected]> Date: 02/05/2009 05:46 PM Subject: Re: Mapping javax.servlet to HttpCore - best practices questions Todd W Lainhart wrote: >> The Servlet API would take care of incoming connections and >> HttpCore would be used to transform the incoming request and forward it >> to the target server? > > That's right. Imagine an AbstractServlet that implementors would derive > from, whose service method looked something like this: > > service(HttpRequest coreRequest, HttpResponse coreResponse); > > The implementor would handle that service method, and then either handle > the business logic there, or forward to another server (i.e. make an HTTP > request to another server). The AbstractServlet's job is to transform the > HttpServletRequest/Response objects to the HttpCore analogues. > Sounds reasonable. > So then the issue becomes, for those clients that are savvy using > HttpCore, what is their expectation for where to find the data that they > would normally find in HttpServletRequest? I'm guessing parameters, and > not context, but this still isn't clear to me from reading the updated > tutorial. > The distinction is quite simple. Use HTTP context for objects that represent session data and can be mutable in the course of the request processing. HTTP context is somewhat similar to the attribute collection of ServletRequest. Use HTTP parameters for simple objects that define behavior of the components and are immutable. The closest Servlet equivalent I can think of is ServletContext / ServletConfig. I'll try to put together an example of a simple reverse proxy using HttpCore (classic I/O) in the coming days. Maybe you'll find it useful. Hope this helps. Oleg > -- Todd > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
