Team,
I just updated the svn with the following modifications:
1. refactored HttpMessageListener to HttpMessageHandler
2. renamed/refactored methods in HttpMessageHandler to help clarify when
each is called by changing the failed overloaded methods and received
methods to be slightly more descriptive
3. changed the calling logic of the handler classes, before we had register
methods for both requests and responses for both handlers and processors.
Though this makes sense for a processor which may want to change the request
or response, it does not make sense for a handler which I can not see
needing a different register for either request handlers or response
handlers since they are one in the same.
4. found that my logic was wrong in the calling order, and corrected it to
follow this logic outlined below:
>From Proxy.java line 302 through 504:
1. proxy receives a request from client
2. proxy parses the request and builds an HttpMessageRequest object from it
If an error occurs during this parse call the registered handlers
error() method
3. proxy then runs through all the registered request processors and
modifies the request based on those
4. proxy then runs through all the registered handlers and calls the
receivedRequest() methods of each
5. proxy then services the request and creates an HttpMessageResponse object
from the resulting reply
If an error occurs during this execution the registered handlers
errorRequest() method is called
6. proxy then runs through all the registered response processors and
modifies the response based on those
7. proxy then runs through all the registered handlers and calls the
receivedResponse() methods of each
8. proxy then passes the response back to the client
If an error occurs during the reply to the client the registered
handlers are called by their errorResponse() method
Hope that helps :)
PS: I just noticed that steps 6 and 7 need to be reversed
|
