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]
