From: John S. <jo...@we...> - 2007-01-29 23:43:34
|
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 |