[
https://issues.apache.org/jira/browse/HTTPCORE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719489#comment-13719489
]
Erik Bunn edited comment on HTTPCORE-346 at 7/25/13 11:51 AM:
--------------------------------------------------------------
Oleg,
This is what I do. Doesn't work. As I originally state, the call to the
HttpAsyncRequestHandler (e.g. in HttpAsyncService.requestReceived() ->
handler.processRequest(...)) takes its HttpContext from an internal State
object, where it is always initialized as an empty BasicHttpContext.
In HttpAsyncService:
public void requestReceived(...) {
...
HttpContext context = state.getContext();
...
HttpAsyncRequestConsumer<Object> consumer =
requestHandler.processRequest(request, context);
...
}
In HttpAsyncService$State:
static class State {
private final BasicHttpContext context;
...
State() {
...
this.context = new BasicHttpContext();
...
}
(This is 4.2.4 code, but at a brief glance at 4.3b looked the same.)
So, back to my original questions, maybe adding one:
4) If none of 1...3, could we simply relax the package private members in
HttpAsyncService to allow extending and customizing this class more?
I can submit a patch, but I'd like someone more familiar with the code to weigh
in first.
Cheers,
//erik
was (Author: ebudan):
Oleg,
This is what I do. Doesn't work. As I originally state, the call to the
HttpAsyncRequestHandler (e.g. in HttpAsyncService.requestReceived() ->
handler.processRequest(...)) takes its HttpContext from an internal State
object, where it is always initialized as an empty BasicHttpContext.
In HttpAsyncService:
public void requestReceived(...) {
...
HttpContext context = state.getContext();
...
HttpAsyncRequestConsumer<Object> consumer =
requestHandler.processRequest(request, context);
...
}
In HttpAsyncService$State:
static class State {
private final BasicHttpContext context;
...
State() {
...
this.context = new BasicHttpContext();
...
}
(This is 4.2.4 code, but a brief glance at 4.3b looked the same.)
So, back to my original questions, maybe adding one:
4) If none of 1...3, could we simply relax the package private members in
HttpAsyncService to allow extending and customizing this class more?
I can submit a patch, but I'd like someone more familiar with the code to weigh
in first.
Cheers,
//erik
> NIO: HttpAsyncService should couple IOSession and HttpContext
> set/getAttribute()
> --------------------------------------------------------------------------------
>
> Key: HTTPCORE-346
> URL: https://issues.apache.org/jira/browse/HTTPCORE-346
> Project: HttpComponents HttpCore
> Issue Type: Wish
> Components: HttpCore NIO
> Affects Versions: 4.2.4, 4.3-beta2
> Reporter: Erik Bunn
> Priority: Minor
>
> Under httpcore-4.1, I wrote code that attached identifying information
> (unique certificate id) to the IOSession attribute context in SSL
> verification (where we have access to IOSession only, ), and utilized that
> information at the request processing stage (where we have access to
> HttpContext). HttpContext.getAttribute() proxied to its parent context,
> eventually reaching the IOSession attributes.
> The refactoring for 4.2.x async processing has decoupled the HttpContext
> object available in the HttpAsyncRequestHandler implementation methods from
> the IOSession. Looking at HttpAsyncService.processRequest(), you can see that
> it provides HttpAsyncRequestHandler.handle() and .processRequest() with the
> (always empty) BasicHttpContext contained in its state.context.
> At both locations, HttpAsyncService does have access to the
> NHttpServerConnection containing the previously established
> SessionHttpContext seen by IOSession.
> 1) Could this context be sent to the HttpAsyncRequestHandler, instead of
> state.context?
> 2) Alternatively, would it be possible to initialize state.context attributes
> with the contents of the session attributes in HttpAsyncService.connected() ?
> 3) Alternatively, would it be possible to modularize HttpAsyncService.state
> creation to allow extending the class and customizing this behaviour?
> There may be security or nio object reuse implications that I am not
> immediately seeing, and which might invalidate connecting the attribute
> storage in this way. I would appreciate your input if that is the case. If
> not, I would claim this is a bug in the recent nio HttpContext refactoring.
> (Marked as minor under the assumption few people need to carry information
> between such separated stages of iosession and request.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
