Menu
▾
▴
Re: [Wpg-proxy-development] design details and impact on unittesting
|
From: John S. <jo...@we...> - 2007-01-30 20:37:08
|
Alan, What would you think of us creating our own ProxyException which can hold the stack trace of the original exception, plus a custom error message, and getRequest(), getResponse() methods that will let the handler walk the stack, go into the request or response, and log or record the error however it likes. The only thing I don't like about making our own exception is having to figure out how to specify the exact error in a way that will be useful to a programmer trying to develop an exception handler method. I originally just renamed the two failed methods that are called when an error happens during the request processing, and the response processing. We could change that to a single failed( ProxyException ) method with the: getRequest(), getResponse() methods plus an errorState() method to return something like: 0 = before request is parsed, or init 1 = during request parsing 2 = while attempting to service the request 3 = during response parsing ... Possibly an Enumeration?? Alan, Juan, please feel free to toss a recommendation out, I am struggling to identify a usable model. I would not mind doing the ProxyException, and can already see how my code would take advantage of that design, however, it may have hidden gotchas I can't see. Remember, one of my favorite things is to print a stack trace with an error, and Exceptions are so good at that, but also we can print that stack trace in the proxy before sending it on to the handler, so that may be the best place for that. That being said, I have no idea...... -----Original Message----- From: John Southerland [mailto:jo...@we...] Sent: Monday, January 29, 2007 5:54 PM To: 'wpg...@li...' Subject: RE: [Wpg-proxy-development] design details and impact on unittesting I should point out one of the reasons I see for passing the exception is the processors and handlers have no context beyond the call itself. The objects do not get destroyed so it is conceivable that the developers could implement a more advanced object that has some internal stuff, but the usage should be to not store any state, but to accept these interupt driven events. That is why the callbacks each take an HttpMessage as an argument. If an error occurs during the actually sending and receiving of the request we need to inform the handlers and pass them any data we have available so they can "handle" it along with our proxy. Again, the handlers will have no context to the method calls the proxy issues during processing of the requests from the clients, so we need to pass as much as possible in the call. Though not entirely explored in my mind yet these handlers may get called more often than you would initially imagine in a serial system. I thought originally about extending an abstract class but then decided against it so the programmer would not have to worry about our internal classes, and could simply take an existing class and implement the handler or process or both on top of it, as in many swing interfaces. I would rather force the programmer to write more methods. Let me refactor what we have into something a little more clear and then look at better error handling in the handler class. This may help us when refering to the different logical calls. Thanks, John -----Original Message----- From: wpg...@li... [mailto:wpg...@li...] On Behalf Of Alan Moran Sent: Monday, January 29, 2007 4:47 PM To: wpg...@li... Subject: Re: [Wpg-proxy-development] design details and impact on unittesting Hi All, adding my 2c based on what we have discussed already.... > Currently the HttpMessageProcessor does the > following three methods for each > request and response if registered [snip] > The goal of this interface is to allow the > programmer to either modify the > message with the process method before allowing it > to continue down the > line, to filter this message via the doSend and > doContinue methods, or both. > Based on the usage and definitions a better name is > needed to keep confusion > to a minimum. > I think this interface and all references to it > would be better named > "Filter" or "Translator" What do you guys think???? I think that Filter or Handler (or even Processor) are fine names that convey that idea of one step in a sequence or chain of events. I think each processor (or whatever we call it) needs a well defined lifecycle concerning what is does (not how it is called, i.e., if it is to continue then this is a decision to be made its calling context etc.) > Second, the HttpMessageListener is not a listener > and needs to be refactored > based on that, also the error methods need to be > rearchitected to be > cleaner, and the received methods are confusing and > ugly. This whole thing > needs redesign. Agreed. Listener makes it sound like an Observer which it is not! In fact I kinda doubt the processor/listener distinction is in fact a real one...but I will study the code some more and touch up my UML tomorrow. > Currently HttpMessageListener looks like this: > > 1. void failed( Exception e ) // failed to even > receive a request from [snip...etc.] The passage of Exceptions as arguments is a first for me - I'm not sure whether I should laugh or cry...anyhow the listener/processor needs only to notify exceptions (i.e., throw them) and the calling context should decide what to do. Here are two possibilities: 1. throw/catch with the option of passage the matter back to the proxy client (not very nice since the user may not want to get involved in that sort of thing) 2. define an ExeptionHandler that defines callbacks for each type of exception that can be raised. The binding of callback to exception is typical template method stuff and can be managed in a base class. The client code can optionally implement an ExceptionHandler (failure to do so means a default one is used) etc. An example of this sort of thing is the ErrorHandler that one sees with SAX parsing architectures. > Next, the received methods which are overloaded to > handle both requests and > responses should probably be renamed receivedRequest > and receivedResponse > respectively to clarify when each is called. Then > the error handlers should > be less overloaded and more descriptive in their > calling state. In that > vein, should we create a hierarchy of Exceptions to > organized the errors > causing the call, or an error enumeration to help > organize the messages? The idioms of request/response handling ought to follow those that most developers would be familiar with in NIO or similar - so we can just take our lead from that perhaps. Exceptions are typed so that we can distinguish error events - we can easily afford to define a handful of exceptions (perhaps based in a single class), this sort of exception hierarchy is common and might even be expected of us. It would also bind nicely to the ExceptionHandler suggestion above if we choose to go down that route. Not so sure about the enumeration - that is not very Java-ish, better define types instead (i.e., classes.) Each exception class should of course contain message information about the errors etc. and should support all the usual features of exceptions classes (e.g., support throwable, nested exceptions etc.) I think we should brace ourselves for a bit of a rewrite of the interfaces but from I have seen of John's stuff already I think that much of the internals can be kept. In all once we have a robust API then the refactor itself will take no time at all. hth, A. ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wpg-proxy-development mailing list Wpg...@li... https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development |
