Menu
▾
▴
wpg-proxy-development
|
From: Alan M. <a_j...@ya...> - 2007-01-28 20:50:22
|
Juan, I gather you are working on some unit testing details so thought I ought to bring you up to speed on some of the interface changes that might affect you. John and I have been reviewing the design and idioms in the current code and have concluded that there is stuff there that will need to be amended (e.g., there is failure handling mechanism that has a life of its own - or it's not Java at least.) I will continue to throw out some thoughts on the design until we can finalize something that could be subjected to unit testing (I'm guessing this might be ready by next weekend say.) In the meantime it is fair to say that the structure and public methods interface will change but that the internals (e.g., the way the utility methods in HttpMessage* work etc.) will probably be just lifted as they are and placed into the new design. I'll keep you posted of developments.... A. ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de |
|
From: <ju...@ag...> - 2007-01-28 21:39:21
|
Hi Alan (and John),
I've been following your discussion about design decisions, but at thi=
s
moment I'm working on something that must be finished by this week (who sai=
d
stress ;), and I can't find time to elaborate on the subject (this is a goo=
d
moment to say that English is not my mother tongue so I'm a bit slow
transferring my thoughts to written English text, hope you'll understand).
By the mid of this week I will elaborate on unit testing and start working
on some tests for HttpMessage*.
Regards.
2007/1/28, Alan Moran < a_j...@ya...>:
>
> Juan,
>
> I gather you are working on some unit testing details
> so thought I ought to bring you up to speed on some of
> the interface changes that might affect you.
John and I have been reviewing the design and idioms
> in the current code and have concluded that there is
> stuff there that will need to be amended (e.g., there
> is failure handling mechanism that has a life of its
> own - or it's not Java at least.) I will continue to
> throw out some thoughts on the design until we can
> finalize something that could be subjected to unit
> testing (I'm guessing this might be ready by next
> weekend say.) In the meantime it is fair to say that
> the structure and public methods interface will change
> but that the internals (e.g., the way the utility
> methods in HttpMessage* work etc.) will probably be
> just lifted as they are and placed into the new
> design.
I'll keep you posted of developments....
>
> A.
>
>
>
>
>
>
> ___________________________________________________________
> Der fr=FChe Vogel f=E4ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Ma=
il: http://mail.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=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Wpg-proxy-development mailing list
> Wpg...@li...
> https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development
>
|
|
From: <ju...@ag...> - 2007-01-29 19:27:08
|
Hi back, I've found a little time to work on the testing issue, and would like to know what do you think about using jUnit 4.1 instead of 3.8. In 4.1, a new annotation based system has been included which makes tests far more elegant (http://www.devx.com/Java/Article/31983/0/page/1 has a comprehensive guide). The 4.1 junit only has one problem, it's integration with ant, but as explained in the previous guide that's a small barrier as there is a JUnit4TestAdapter class included for convenience. If you agree with using 4.1 is just a matter of changing the ivy.xml... Besides this, i've uploaded an updated version of the build.xml file that includes a target to compile&run the (to be done) tests found on ${ wpg.proxy.test}, and a target to run the sample Proxy class, let me know what do you think of it. Back to work |
|
From: John S. <jo...@we...> - 2007-01-29 19:37:34
|
Juan, Considering we are starting from scratch I see nothing wrong with = upgrading our junit version, however isn=92t their already a =93test=94 build.xml = target? Can=92t we just use that? Thanks, John =20 =20 _____ =20 From: wpg...@li... [mailto:wpg...@li...] On Behalf = Of Juan Gonz=E1lez Sent: Monday, January 29, 2007 2:26 PM To: wpg...@li... Subject: Re: [Wpg-proxy-development] design details and impact on unittesting =20 Hi back, I've found a little time to work on the testing issue, and would like = to know what do you think about using jUnit 4.1 instead of 3.8. In 4.1, a = new annotation based system has been included which makes tests far more = elegant ( http://www.devx.com/Java/Article/31983/0/page/1 has a comprehensive guide). The 4.1 junit only has one problem, it's integration with ant, = but as explained in the previous guide that's a small barrier as there is a JUnit4TestAdapter class included for convenience. If you agree with = using 4.1 is just a matter of changing the ivy.xml... Besides this, i've uploaded an updated version of the build.xml file = that includes a target to compile&run the (to be done) tests found on ${wpg.proxy.test}, and a target to run the sample Proxy class, let me = know what do you think of it.=20 Back to work |
|
From: <ju...@ag...> - 2007-01-29 20:22:47
|
Hi john, 2007/1/29, John Southerland <jo...@we...>: > > Juan, > > Considering we are starting from scratch I see nothing wrong with > upgrading our junit version, however isn't their already a "test" > build.xml target? Can't we just use that? > > Thanks, John > Well, that target just compiles the tests, but what I added compiles them (through compile-test target) AND run them using the ant infraestructure, which (at least for me) is more adequate, but as I uploaded it to svn, just look at the updated file, and if you prefer we'll get back to the just-compile version. |
|
From: John S. <jo...@we...> - 2007-01-29 20:33:14
|
Juan, Sorry, my mistake, that looks good. Thanks, John =20 =20 =20 _____ =20 From: wpg...@li... [mailto:wpg...@li...] On Behalf = Of Juan Gonz=E1lez Sent: Monday, January 29, 2007 3:23 PM To: wpg...@li... Subject: Re: [Wpg-proxy-development] design details and impact on unittesting =20 Hi john, 2007/1/29, John Southerland <jo...@we...>: Juan, Considering we are starting from scratch I see nothing wrong with = upgrading our junit version, however isn't their already a "test" build.xml = target? Can't we just use that? Thanks, John=20 Well, that target just compiles the tests, but what I added compiles = them (through compile-test target) AND run them using the ant = infraestructure, which (at least for me) is more adequate, but as I uploaded it to svn, = just look at the updated file, and if you prefer we'll get back to the just-compile version.=20 |
|
From: <ju...@ag...> - 2007-01-29 20:47:34
|
Hi back, > Juan, > > Sorry, my mistake, that looks good. > > Thanks, John > I didnt explain myself very well on the "new" test target, sorry for my side too. I forgot to mention that i've also added a new arg to the javac command (-Xlint:unchecked) which show unsafe usages on classes that support Generics (like Vector, Map,...), as soon as you confirm which classes will stay the same after the re-struct Alan and you are working on I would like to clean all up and use type-safe generics whenever is possible (this helps to understand the code and bulletproof it against many mistakes we may make). Please, take a look at the current output of "ant clean" and tell me what you think of all these. Thanks, Juan |
|
From: <ju...@ag...> - 2007-01-29 20:50:43
|
Of course, when I said "ant clean", I meant "ant" ;) 2007/1/29, Juan Gonz=E1lez <ju...@ag...>: > > Hi back, > > > Juan, > > > > Sorry, my mistake, that looks good. > > > > Thanks, John > > > > I didnt explain myself very well on the "new" test target, sorry for my > side too. > I forgot to mention that i've also added a new arg to the javac command > (-Xlint:unchecked) which show unsafe usages on classes that support Gener= ics > (like Vector, Map,...), as soon as you confirm which classes will stay th= e > same after the re-struct Alan and you are working on I would like to cle= an > all up and use type-safe generics whenever is possible (this helps to > understand the code and bulletproof it against many mistakes we may make)= . > > Please, take a look at the current output of "ant clean" and tell me what > you think of all these. > > Thanks, Juan > |
|
From: Alan M. <a_j...@ya...> - 2007-01-29 21:33:29
|
Looks good to me and if the Junit 4.x can be made to work ok with Ant then I'm easy too about using that as we have little baggage here. Thanks, A. --- Juan González <ju...@ag...> schrieb: > Of course, when I said "ant clean", I meant "ant" ;) > > 2007/1/29, Juan González <ju...@ag...>: > > > > Hi back, > > > > > Juan, > > > > > > Sorry, my mistake, that looks good. > > > > > > Thanks, John > > > > > > > I didnt explain myself very well on the "new" > test target, sorry for my > > side too. > > I forgot to mention that i've also added a new > arg to the javac command > > (-Xlint:unchecked) which show unsafe usages on > classes that support Generics > > (like Vector, Map,...), as soon as you confirm > which classes will stay the > > same after the re-struct Alan and you are working > on I would like to clean > > all up and use type-safe generics whenever is > possible (this helps to > > understand the code and bulletproof it against > many mistakes we may make). > > > > Please, take a look at the current output of "ant > clean" and tell me what > > you think of all these. > > > > Thanks, Juan > > > > ------------------------------------------------------------------------- > 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 > --------------------------------------------------- You can find my GPG key (a_j...@ya...) at ETH PGP Keyserver: http://www.tik.ee.ethz.ch/~pgp/ --------------------------------------------------- ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de |
|
From: John S. <jo...@we...> - 2007-01-29 21:29:53
|
Juan, I=92m glad your looking at those details before we end up with too much = code to clean up. Sorry I was so very lazy on first writing. I do need to share some thoughts on the rewrite of the interfaces for = the processor and listener interfaces. =20 Currently the HttpMessageProcessor does the following three methods for = each request and response if registered 1. boolean doContinue( HttpMessage in ) // keep processing through the Vector of registered HttpMessageProcessors 2. boolean doSend( HttpMessage in ) // send this message on or abort the transmission? 3. HttpMessage process( HttpMessage in ) // returns a modified message after being changed by this object =20 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. =20 I think this interface and all references to it would be better named =93Filter=94 or =93Translator=94 What do you guys think???? =20 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. =20 Currently HttpMessageListener looks like this: 1. void failed( Exception e ) // failed to even receive a request from the client 2. void failed( HttpMessageRequest request, Exception e ) // failed to get a response for the given request 3. void failed( HttpMessageResponse response, HttpMessageRequest request, Exception e ) //failed to send the response for the request = back to the client 4. void received( HttpMessageRequest request ) //received a request from the client 5. void received( HttpMessageResponse response, HttpMessageRequest request ) // received a response from the server for the request from = the client =20 I=92m not incredibly happy with all this, and think first that the = entire interface and all references should be changed to Handler or = EventHandler or something like that, since that is in essence what is going on here. 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? = =20 My preference here is to remove these methods and create a special = Exception that contains an enumeration of reasons as well as get methods for the request and response if available. This may =93over simplify=94 our = errors but it would be easier for me as a user of a library to have a set method to handle all errors and then based on what I want to query at the point of error have that data available in an exception being passed. To = simplify this we should probably not use an exception at all but use a separate object to hold this information. This is where I am confused does anyone have any ideas on how errors = should be handled? Alan? Thanks, John =20 =20 =20 _____ =20 From: wpg...@li... [mailto:wpg...@li...] On Behalf = Of Juan Gonz=E1lez Sent: Monday, January 29, 2007 3:47 PM To: wpg...@li... Subject: Re: [Wpg-proxy-development] design details and impact on unittesting =20 Hi back, Juan, Sorry, my mistake, that looks good. Thanks, John I didnt explain myself very well on the "new" test target, sorry for my side too.=20 I forgot to mention that i've also added a new arg to the javac = command (-Xlint:unchecked) which show unsafe usages on classes that support = Generics (like Vector, Map,...), as soon as you confirm which classes will stay = the same after the re-struct Alan and you are working on I would like to = clean all up and use type-safe generics whenever is possible (this helps to understand the code and bulletproof it against many mistakes we may = make).=20 Please, take a look at the current output of "ant clean" and tell me = what you think of all these. Thanks, Juan |
|
From: Alan M. <a_j...@ya...> - 2007-01-29 21:47:13
|
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 |
|
From: John S. <jo...@we...> - 2007-01-29 22:53:50
|
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 |
|
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 |
|
From: Alan M. <a_j...@ya...> - 2007-01-31 08:10:26
|
Hi John,
I think the following is how exception handling would normally be done: We define ProxyException (plus possibly one or two other types depending on our needs) - this has the usual constructors i.e., message constructor, exception constructor, throwable constructor etc. that allow us to instantiate a ProxyException with a custom message e.g.,
new ProxyException("Remote host cannot be contacted!");
or nest our exception in another one, e.g.,
try {
...try to do something...
} catch (IOException e) {
throw new ProxyException("Cannot establish connection", e);
}
all the usual methods are on ProxyException (e.g., getMessage, getCause etc.) There is generally no need to put into a stack trace anything other than exceptions info - the context will extract what it needs when raising an exception e.g.,
new ProxyException("cannot connect to host " + request.getHost());
etc. but sometimes it is necessary (e.g., in a specific subclass of ProxyException) to add state information e.g., a RemoteServerException extension of ProxyException might offer a getHost method etc.
Now to types: we instantiate ProxyException when we need to report different circumstances that give rise to a proxy error (e.g., with different messages etc.) but we used different _types_ (e.g., subclasses of ProxyException) when we want to control flow e.g., in try/catch blocks or within the template method of a handler etc. or when we have context state information that needs dealing with.
Types would be used when you are suggesting enumerations - I really don't think we should return codes, enums or similar in this context (they can be used for control of FSAs and that sort of thing but not here :)
I will add the "canoncial" ProxyException class tonight with all the usual constructors and stuff and you can see what I mean above - this approach would be recognisable to Java developers and that recognition is probably important since it may be client code that has to deal with this. To stimulate discussion I'll also add the ExceptionHandler stuff that allows us to "outsource" callbacks to the client code - this could clear up a lot in one go.
hth.
A.
John Southerland <jo...@we...> schrieb:
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
-------------------------------------------------------------------------
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
---------------------------------
NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever. |
|
From: <ju...@ag...> - 2007-01-31 15:00:21
|
Hi Alan,
2007/1/31, Alan Moran <a_j...@ya...>:
>
> Hi John,
>
> I think the following is how exception handling would normally be
>
[snip]
>
> I will add the "canoncial" ProxyException class tonight with all the usua=
l
> constructors and stuff and you can see what I mean above - this approach
> would be recognisable to Java developers and that recognition is probably
> important since it may be client code that has to deal with this.
>
I agree we should keep using the exception infraestructure for error
handling, but I also believe it's not that hard to include the "state" enum
suggested by john, just as an aditional source of info to know where to
start seeking for the problem when an error happens, just something like:
public enum ProxyErrorType {
BeforeRequest,
ParsingRequest,
ServingRequest,
ParsingResponse;
private String message;
ProxyErrorType(String message)
{
this.message =3D message;
}
public String getMessage() {
return message;
}
}
And including a constructor to ProxyException base class like:
public ProxyException(ProxyErrorType type, Throwable cause) {
super(cause);
this.type =3D type
}
Of course with a private property and a getter for it.
What do you think of it? It is just another way to classify the errors we
can get, but maybe what we need is to define a class containing the
"Context" of the given error (of course the needed fields for the "Context"
class have to be determined), and include that information with the
ProxyException so it can be handled from the caller, does it make sense?
To stimulate discussion I'll also add the ExceptionHandler stuff that allow=
s
> us to "outsource" callbacks to the client code - this could clear up a lo=
t
> in one go.
>
I'm just waiting to see it ;)
hth.
> A.
>
Just my 0.02=80
Juan.
|
|
From: <ju...@ag...> - 2007-01-31 15:03:04
|
Now that I see the enum written, and after mentioning the "Context" class, I feel that the later is a better solution because the enum doesn't allow to change the message for any given value when used (only from within the enum declaration), and it doesn't include any really usefull info, so what do you think about the "Context" class concept? |
|
From: John S. <jo...@we...> - 2007-01-31 16:02:54
|
I agree on all proposals, I am willing to sit back and take a look at = what Alan puts together. I admittedly have not thought deeply about how exceptions/errors should be handled. I'm not quite sure which = exceptions we should pass back to the handlers. This is one of those places where the question, in my mind, is should we handle most errors and just send a = simple error message to the handler for "handling" or should we not only handle = an error condition but also allow a plugin to handle error messages? Maybe that is a design area I have not explored fully because of my focus on functionality, perhaps when we start writing test cases we should make = sure to include negative tests and make sure to test the error handling conditions. Perhaps when our user community grows a bit and people = start producing bugs we can modify it a bit more then, but that just speaks volumes about having a well defined error mechanism so old code will not break from one revision to the next. OK, I will wait and see, my mind is having problems thinking about this = for some reason. ________________________________________ From: wpg...@li... [mailto:wpg...@li...] On Behalf = Of Juan Gonz=E1lez Sent: Wednesday, January 31, 2007 10:03 AM To: wpg...@li... Subject: Re: [Wpg-proxy-development] design details and impact on unittesting Now that I see the enum written, and after mentioning the "Context" = class, I=A0 feel that the later is a better solution because the enum doesn't = allow to change the message for any given value when used (only from within = the enum declaration), and it doesn't include any really usefull info, so = what do you think about the "Context" class concept?=20 |
Thanks for helping keep SourceForge clean.
X