Menu
▾
▴
wpg-proxy-development — Developer Mailing List
You can subscribe to this list here.
| 2007 |
Jan
(56) |
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|---|
|
From: John B. S. <Jo...@we...> - 2007-11-04 23:16:13
|
Alan, Can you take a look at the latest revision in svn? I am trying to work on the ssl support again, my schedule has been pretty hectic. I have the socket attempting to handshake with the browser, but can not get past an error saying no ciphers in common. I hope you=B9ve been well, this library has worked fine for http requests, I hope I can get ssl working before I get busy again. Thanks, John |
|
From: John S. <jo...@we...> - 2007-02-26 17:41:59
|
Team, I just released version 0.0.3 which is all of our modifications in the refactoring of the original code base, improved ssl support (though not yet working), and some minor and major bug fixes. I had never tried to use the library from a windows machine, until Sunday while trying to record some scripts requiring Internet Explorer, and I found the following issue: When a windows client is using the proxy only a fragment of the response was being returned, this was verified on both IE7 and Firefox. The cause was that the socket().getSendBufferSize() was 8K, and that was all that was actually being written to the client, even with a long sleep before the socket close, so I tried increasing the size to something ridiculous and that confirmed the size issue. The solution was to rewrite the entire response write mechanism to loop through the available data and write it to the socket with a 100ms sleep between iterations, writing only the send buffer size at a time. I got a little annoyed at this smaller than unix buffer size and decided to setSendBufferSize( 32*1024 ), although the default linux size was 24k, this seems to work in both worlds just fine. We may either paramterize this or just see if anyone complains about us manhandling the send buffer size. I'm glad to be knocking out these bugs, and I think we have put together one hell of a useful library. I am going to try to keep up with revisions when we fix more bugs, and hope to use the 0.1.0 revision as our first ssl test revision, though I am not sure of everyone's schedule, I hope to hack on it in the next two weeks. Feel free to add junit tests and play with ssl at your convenience and thank you for everything you guys have done on this project, it would still be very ugly and half useful had it not been for Juan's extensive refactoring and debugging, and don't think I didn't notice all the cleanup Alan did to all my ugly ssl stuff ;) I had to use this library again for some "real" work and it is much better than the stuff I had in 0.0.1, great job guys! Thanks, John |
|
From: John S. <jo...@we...> - 2007-02-20 17:47:23
|
Alan, I've got a little time to work on the proxy, and I wanted to try and ignore the man-in-the-middle stuff for now and just get it working as a basic proxy, I tried taking out the local ssl server and client to instead just redirect the io from the remote client to the remote target server directly, unfortunately I get the same hanging response when I try that connection. I am unsure of how to tell the client he is now connected to an ssl server and so a handshake should begin. Can you help me learn this process? Who initiates that connection, the client or the server? The proxy spec is to make the connection then return the 200 response and let the browser do something from there. I'm trying to study this but as you know the documentation is specification, and hard to decipher at times. Do you have some time to look at the code in the next day or two? I'm going to keep hacking away and updating often as I do. Juan, I like the cleanup and may pull some of the internal classes out as well, I'm not sure yet what the ssl support will look like. Thanks, John |
|
From: John S. <jo...@we...> - 2007-02-15 19:50:10
|
Guys, Just a quick heads up. I checked out the code updates and they make sense and the refactoring looks good! I have been pretty busy lately, as I am sure you guys are as well. I like the state of our code, and think we are pretty much refactored, except for the error handling stuff Alan was going to start on. I am wondering if we should consider releasing another "development" dist so people can download and begin critiquing. I unfortunately am having to backport my application which uses this library to use ExProxy so I can record https, but I remain hopeful we can add that support to this opensource version soon. We broke the 100+ download record recently, so everyone wear a little ink star on one of your wrists, someone out there is finding this utility library of some use :) |
|
From: Alan M. <a_j...@ya...> - 2007-02-05 07:07:05
|
John, No worries on that score :) will get back into things soon again! A. --- John Southerland <jo...@we...> schrieb: > Alan, > Sorry to hear that, but I am glad you were not just > annoyed with my > ramblings and deciding to ignore me, take care and > we will see you again > when you have more time :) > --------------------------------------------------- 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: <ju...@ag...> - 2007-02-04 23:35:28
|
Hi back,
i'm working on the refactoring and hope to put a working copy before
going to sleep, we'll speak back when I've it ready.
Cheers.
|
|
From: John S. <jo...@we...> - 2007-02-04 22:11:53
|
Hi John,
first, sorry for the delay answering, but I had a bad combination this week:
many work + bad cold + notebook crash, when I came back home I just had no
strength to answer (or even read) any mail :(
[Southerland, John B] No Problem at all, I was beginning to get worried
everyone was upset at all my annoying additions ;)
Now, hands on work, I've looked at your actual implementation of
ProxyStatistics and your additions to the Proxy class, and they made me feel
like the Proxy class is getting quite heavy, now it's doing most of the job
including: reception, parsing, processing and responding to any request. For
me, it seems more reasonable to extract every possible functionality from
it, starting with all the local requests for statistics, and delegating all
the processing to leave the Proxy class more like a functionality caller
than implementer (This is more a refactoring process anyway). My proposal is
to separate the Proxy class in:
- ProxyProcessor: Final class with methods extracted from Proxy to
handle each received request. This class implements the (Runnable |
Callable) interface, read a bit more to know why.
[Southerland, John B] That does make sense to me, considering the HTTP
nature of the transactions, we don't need to track any information between
requests.
- ProxyRegistry: Here we keep every HttpMessageHandler/Processor in an
static environment. Provides public static methods to register/unregister
handlers and processors, and protected static methods to call each
handler/processor with each HttpMessage.
[Southerland, John B] Wouldn't we just end up having to wrap all the calls
to addHandler and addProcessor through the main proxy or would you recommend
adding something like Proxy.getProxyRegistry().addHandler( new
MyHandlerObject )?
I guess I can see that :)
- Proxy: This class keeps doing the loop to receive each new request,
and also has a ExecutorService(fixedThreadPool) of ProxyProccessors to
process each request, that's why ProxyProccessor implements Runnable or
Callable, we should decide whether it should return something or not,
returning some data may be a good way to populate statistics...
[Southerland, John B] or perhaps register a ProxyStatistics object and allow
it to use synchronized methods to update it?
- Extract the html construction and detection to ProxyStatistics, or
even including an interface and default implementation for something like
ProxyStatisticsFormatter, but this depends on how many functionality we end
with in the web page.
[Southerland, John B] I agree that the html construction should probably be
done in the ProxyStatistics object, though I am not sure we need to go so
far as to create a plugin hierarchy for it, as it may only benefit us in
debugging the proxy itself, though other developers may need that as well.
Hopefully we can expand it to support the entire scope of possible usage
without having to go overboard.
About the web page, the question I see is how lightweight do we want our
library to be. I can think few features to add to that web page, but it
feels like they maybe out of scope or overwhelming for a lightweight library
(anyway some would require extra functionality to be added to the library):
[Southerland, John B] Maybe we should enable property configuration, to
allow for all the features?
-pass protection: This is a must have, I think. As an initial solution
we can add a new singleton class like ProxyWebUsers to keep track of
authorized users and put some authorization mechanism within
ProxyStatistics.
[Southerland, John B] Agreed, in fact we may need to support quite a bit of
authentication, to allow developers to enable users of the proxy at runtime
and not just accept all traffic, for instance on my machine here, I use the
original version of this library to record web scripts for performance
testing. One of the problems I have is that ANY http traffic coming from my
machine gets routed through my temporary proxy, I would rather have the
ability to authenticate the particular browser to allow me to record yahoo
weather update free performance scripts. This would also apply to the proxy
statistics query. In the future it would also allow developers to create
context sensitive proxy's that allow some users different features than
others. We should definitely explore this further.
-filter creation for persistent statistics (say keep all GET requests
on file gets.txt)
[Southerland, John B] I was just about to write a log4j plugin to handle
collection all messages and look into adding support for more detailed
queries to the internal web server to handle viewing logs. Though an issue
of storage and size does become an issue. I am pretty crazy here, and wanted
to take a breath before creating a sql server to store all those log
messages, or an ever growing array :(
-rule creation for traffic control (don't serve such or such type of
request)
[Southerland, John B] isn't this the entire point of the Processors? I
wouldn't want the web interface to turn into a proxy admin interface, just
query, or read only type operations.
-configure caching rules: maybe we should add some caching facility
[Southerland, John B] this may be a separate topic, we could implement the
Cache-Control options, but I would want to make that a configuration
property, since my stuff does not like cache, and I'm sure others may need
the same.
-just about anything we can do programatically, but through a web page
(of course not everything, but common things)
[Southerland, John B] as I said in the rule creation section, I would like
to keep the web page to stats only, otherwise we are becoming a full proxy,
and we will have to deal with an entirely new set of users..
End Users ;) Ugly
What do you think of all this?
[Southerland, John B] I love it! Let me clean up the proxy stats stuff, and
move the html generation to the object itself, as well as a few helper
functions, and registry of the Proxy class until the refactor of the Proxy
moves handlers into another class. Would you like to take a go at
refactoring the Proxy and breaking it up as you discussed? I will be happy
to sit back and let you hack away .
Regards.
PS: I must go out for at least one hour, but i'll be back as latest by 21:00
UTC
2007/2/2, John Southerland < jo...@we...>:
Lol, did I say something wrong?
-----Original Message-----
From: John Southerland [mailto:jo...@we...]
Sent: Wednesday, January 31, 2007 4:57 PM
To: ' wpg...@li...
<mailto:wpg...@li...> '
Subject: RE: What should a web interface contain?
SVN updated, we have a basic web page returned with usage statistics
presented via a web page when you point your browser at the proxy.
I added several methods to enable/disable this capability, and still need to
write a log4j appender that will collect 50/100/500 messages in a stack for
us to display in this page, but I will wait until we iron out the details of
what this page should do, and how it should do it, please respond whenever
you can to the questions in the original email, I hope this capability isn't
just an annoying window dressing that no one really wants. ;)
Thanks, John
-----Original Message-----
From: John Southerland [mailto:jo...@we...
<mailto:jo...@we...> ]
Sent: Wednesday, January 31, 2007 11:13 AM
To: ' wpg...@li...'
Subject: What should a web interface contain?
Team,
I have been thinking about expanding a feature of the proxy server itself.
I want to make sure the proxy remains a simple library but I realize we also
need some level of instrumentation to allow us to debug and give developers
a simple way to troubleshoot their code. I had always intended to add a
simple web interface that will allow people to point their browser directly
at the proxy and get usage statistics.
This is a little tricky, but if we get a request that is not destined for a
remote host, but the proxy itself, then we can ignore the rules and return
some statistics such as:
Number of processors and handlers registered
Connection statistics such as number of requests processed and the
success/failure counts as well as durations
A simple log display of the last 50/100/500 messages logged
What other information would you like to see in a status page?
Should we user/pass protect this information?
Possibly allow enabling or disabling this feature via enableStatusBrowser(
Boolean ) and isStatusBrowserEnabled() methods?
Does this even seem useful? Or does it seem more "window dressing"?
I know I personally don't worry about such trivial things while developing,
but I wrote the stupid library, and know somewhat what is happening via
log4j.
I don't want to stop the progress going on, but think I can work this into
the code without breaking anyone elses changes.
Thanks, John
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
&kid=120709&bid=263057&dat=121642
_______________________________________________
Wpg-proxy-development mailing list
Wpg...@li...
https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development
|
|
From: John S. <jo...@we...> - 2007-02-04 20:03:06
|
Alan, Sorry to hear that, but I am glad you were not just annoyed with my ramblings and deciding to ignore me, take care and we will see you again when you have more time :) =20 > -----Original Message----- > From: wpg...@li... [mailto:wpg- > pro...@li...] On Behalf Of Alan = Moran > Sent: Sunday, February 04, 2007 12:12 PM > To: wpg...@li... > Subject: [Wpg-proxy-development] ...may go quite for a bit :) >=20 > ..am dealing with a number of work issues right now so > you'll not hear much from me for a little while - will > get back into the project again once everything > quietens down again... >=20 > atb, > A. >=20 > --------------------------------------------------- > You can find my GPG key (a_j...@ya...) at > ETH PGP Keyserver: http://www.tik.ee.ethz.ch/~pgp/ > --------------------------------------------------- >=20 >=20 >=20 >=20 >=20 >=20 > ___________________________________________________________ > Der fr=FChe Vogel f=E4ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! = Mail: > http://mail.yahoo.de >=20 > = -------------------------------------------------------------------------= > Using Tomcat but need to do more? Need to support web services, = security? > Get stuff done quickly with pre-integrated technology to make your job > easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 > _______________________________________________ > Wpg-proxy-development mailing list > Wpg...@li... > https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development |
|
From: <ju...@ag...> - 2007-02-04 18:28:15
|
Hi John,
first, sorry for the delay answering, but I had a bad combination this week:
many work + bad cold + notebook crash, when I came back home I just had no
strength to answer (or even read) any mail :(
Now, hands on work, I've looked at your actual implementation of
ProxyStatistics and your additions to the Proxy class, and they made me feel
like the Proxy class is getting quite heavy, now it's doing most of the job
including: reception, parsing, processing and responding to any request. For
me, it seems more reasonable to extract every possible functionality from
it, starting with all the local requests for statistics, and delegating all
the processing to leave the Proxy class more like a functionality caller
than implementer (This is more a refactoring process anyway). My proposal is
to separate the Proxy class in:
- ProxyProcessor: Final class with methods extracted from Proxy to
handle each received request. This class implements the (Runnable |
Callable) interface, read a bit more to know why.
- ProxyRegistry: Here we keep every HttpMessageHandler/Processor in an
static environment. Provides public static methods to register/unregister
handlers and processors, and protected static methods to call each
handler/processor with each HttpMessage.
- Proxy: This class keeps doing the loop to receive each new request,
and also has a ExecutorService(fixedThreadPool) of ProxyProccessors to
process each request, that's why ProxyProccessor implements Runnable or
Callable, we should decide whether it should return something or not,
returning some data may be a good way to populate statistics...
- Extract the html construction and detection to ProxyStatistics, or
even including an interface and default implementation for something like
ProxyStatisticsFormatter, but this depends on how many functionality we end
with in the web page.
About the web page, the question I see is how lightweight do we want our
library to be. I can think few features to add to that web page, but it
feels like they maybe out of scope or overwhelming for a lightweight library
(anyway some would require extra functionality to be added to the library):
-pass protection: This is a must have, I think. As an initial solution
we can add a new singleton class like ProxyWebUsers to keep track of
authorized users and put some authorization mechanism within
ProxyStatistics.
-filter creation for persistent statistics (say keep all GET requests
on file gets.txt)
-rule creation for traffic control (don't serve such or such type of
request)
-configure caching rules: maybe we should add some caching facility
-just about anything we can do programatically, but through a web page
(of course not everything, but common things)
What do you think of all this?
Regards.
PS: I must go out for at least one hour, but i'll be back as latest by 21:00
UTC
2007/2/2, John Southerland < jo...@we...>:
>
> Lol, did I say something wrong?
>
>
>
> -----Original Message-----
> From: John Southerland [mailto:jo...@we...]
> Sent: Wednesday, January 31, 2007 4:57 PM
> To: ' wpg...@li...'
> Subject: RE: What should a web interface contain?
>
> SVN updated, we have a basic web page returned with usage statistics
> presented via a web page when you point your browser at the proxy.
> I added several methods to enable/disable this capability, and still need
> to
> write a log4j appender that will collect 50/100/500 messages in a stack
> for
> us to display in this page, but I will wait until we iron out the details
> of
> what this page should do, and how it should do it, please respond whenever
> you can to the questions in the original email, I hope this capability
> isn't
> just an annoying window dressing that no one really wants. ;)
> Thanks, John
>
>
> -----Original Message-----
> From: John Southerland [mailto:jo...@we... ]
> Sent: Wednesday, January 31, 2007 11:13 AM
> To: ' wpg...@li...'
> Subject: What should a web interface contain?
>
> Team,
> I have been thinking about expanding a feature of the proxy server itself.
>
> I want to make sure the proxy remains a simple library but I realize we
> also
> need some level of instrumentation to allow us to debug and give
> developers
> a simple way to troubleshoot their code. I had always intended to add a
> simple web interface that will allow people to point their browser
> directly
> at the proxy and get usage statistics.
>
> This is a little tricky, but if we get a request that is not destined for
> a
> remote host, but the proxy itself, then we can ignore the rules and return
>
> some statistics such as:
> Number of processors and handlers registered
> Connection statistics such as number of requests processed and the
> success/failure counts as well as durations
> A simple log display of the last 50/100/500 messages logged
>
> What other information would you like to see in a status page?
> Should we user/pass protect this information?
> Possibly allow enabling or disabling this feature via enableStatusBrowser(
> Boolean ) and isStatusBrowserEnabled() methods?
> Does this even seem useful? Or does it seem more "window dressing"?
> I know I personally don't worry about such trivial things while
> developing,
> but I wrote the stupid library, and know somewhat what is happening via
> log4j.
>
> I don't want to stop the progress going on, but think I can work this into
> the code without breaking anyone elses changes.
> Thanks, John
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Wpg-proxy-development mailing list
> Wpg...@li...
> https://lists.sourceforge.net/lists/listinfo/wpg-proxy-development
>
|
|
From: Alan M. <a_j...@ya...> - 2007-02-04 17:12:14
|
..am dealing with a number of work issues right now so you'll not hear much from me for a little while - will get back into the project again once everything quietens down again... atb, A. --------------------------------------------------- You can find my GPG key (a_j...@ya...) at ETH PGP Keyserver: http://www.tik.ee.ethz.ch/~pgp/ --------------------------------------------------- ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de |
|
From: John S. <jo...@we...> - 2007-02-02 16:46:14
|
Lol, did I say something wrong? -----Original Message----- From: John Southerland [mailto:jo...@we...] Sent: Wednesday, January 31, 2007 4:57 PM To: 'wpg...@li...' Subject: RE: What should a web interface contain? SVN updated, we have a basic web page returned with usage statistics presented via a web page when you point your browser at the proxy. I added several methods to enable/disable this capability, and still need to write a log4j appender that will collect 50/100/500 messages in a stack for us to display in this page, but I will wait until we iron out the details of what this page should do, and how it should do it, please respond whenever you can to the questions in the original email, I hope this capability isn't just an annoying window dressing that no one really wants. ;) Thanks, John -----Original Message----- From: John Southerland [mailto:jo...@we...] Sent: Wednesday, January 31, 2007 11:13 AM To: 'wpg...@li...' Subject: What should a web interface contain? Team, I have been thinking about expanding a feature of the proxy server itself. I want to make sure the proxy remains a simple library but I realize we also need some level of instrumentation to allow us to debug and give developers a simple way to troubleshoot their code. I had always intended to add a simple web interface that will allow people to point their browser directly at the proxy and get usage statistics. This is a little tricky, but if we get a request that is not destined for a remote host, but the proxy itself, then we can ignore the rules and return some statistics such as: Number of processors and handlers registered Connection statistics such as number of requests processed and the success/failure counts as well as durations A simple log display of the last 50/100/500 messages logged What other information would you like to see in a status page? Should we user/pass protect this information? Possibly allow enabling or disabling this feature via enableStatusBrowser( Boolean ) and isStatusBrowserEnabled() methods? Does this even seem useful? Or does it seem more "window dressing"? I know I personally don't worry about such trivial things while developing, but I wrote the stupid library, and know somewhat what is happening via log4j. I don't want to stop the progress going on, but think I can work this into the code without breaking anyone elses changes. Thanks, John |
|
From: John S. <jo...@we...> - 2007-01-31 21:57:14
|
SVN updated, we have a basic web page returned with usage statistics presented via a web page when you point your browser at the proxy. I added several methods to enable/disable this capability, and still need to write a log4j appender that will collect 50/100/500 messages in a stack for us to display in this page, but I will wait until we iron out the details of what this page should do, and how it should do it, please respond whenever you can to the questions in the original email, I hope this capability isn't just an annoying window dressing that no one really wants. ;) Thanks, John -----Original Message----- From: John Southerland [mailto:jo...@we...] Sent: Wednesday, January 31, 2007 11:13 AM To: 'wpg...@li...' Subject: What should a web interface contain? Team, I have been thinking about expanding a feature of the proxy server itself. I want to make sure the proxy remains a simple library but I realize we also need some level of instrumentation to allow us to debug and give developers a simple way to troubleshoot their code. I had always intended to add a simple web interface that will allow people to point their browser directly at the proxy and get usage statistics. This is a little tricky, but if we get a request that is not destined for a remote host, but the proxy itself, then we can ignore the rules and return some statistics such as: Number of processors and handlers registered Connection statistics such as number of requests processed and the success/failure counts as well as durations A simple log display of the last 50/100/500 messages logged What other information would you like to see in a status page? Should we user/pass protect this information? Possibly allow enabling or disabling this feature via enableStatusBrowser( Boolean ) and isStatusBrowserEnabled() methods? Does this even seem useful? Or does it seem more "window dressing"? I know I personally don't worry about such trivial things while developing, but I wrote the stupid library, and know somewhat what is happening via log4j. I don't want to stop the progress going on, but think I can work this into the code without breaking anyone elses changes. Thanks, John |
|
From: John S. <jo...@we...> - 2007-01-31 16:12:54
|
Team, I have been thinking about expanding a feature of the proxy server itself. I want to make sure the proxy remains a simple library but I realize we also need some level of instrumentation to allow us to debug and give developers a simple way to troubleshoot their code. I had always intended to add a simple web interface that will allow people to point their browser directly at the proxy and get usage statistics. This is a little tricky, but if we get a request that is not destined for a remote host, but the proxy itself, then we can ignore the rules and return some statistics such as: Number of processors and handlers registered Connection statistics such as number of requests processed and the success/failure counts as well as durations A simple log display of the last 50/100/500 messages logged What other information would you like to see in a status page? Should we user/pass protect this information? Possibly allow enabling or disabling this feature via enableStatusBrowser( Boolean ) and isStatusBrowserEnabled() methods? Does this even seem useful? Or does it seem more "window dressing"? I know I personally don't worry about such trivial things while developing, but I wrote the stupid library, and know somewhat what is happening via log4j. I don't want to stop the progress going on, but think I can work this into the code without breaking anyone elses changes. Thanks, John |
|
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 |
|
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: <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: 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: 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-30 19:48:12
|
PMG good ! --- John Southerland <jo...@we...> schrieb: > Team, > Ok, I have been a little busy. I cleaned up the > generics, so we don't see > any warnings on compile now. > I also added PMD (http://pmd.sourceforge.net/) > options to the build process, > to help identify issues and such, attached are the > latest reports. > I also deleted the build directories from svn since > that was mucking up my > clean and rebuild. > I cleaned up a few method calls and minor things, > still more to be done. > Thanks, John --------------------------------------------------- You can find my GPG key (a_j...@ya...) at ETH PGP Keyserver: http://www.tik.ee.ethz.ch/~pgp/ --------------------------------------------------- ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de |
|
From: John S. <jo...@we...> - 2007-01-30 18:58:17
|
Team, Ok, I have been a little busy. I cleaned up the generics, so we don't see any warnings on compile now. I also added PMD (http://pmd.sourceforge.net/) options to the build process, to help identify issues and such, attached are the latest reports. I also deleted the build directories from svn since that was mucking up my clean and rebuild. I cleaned up a few method calls and minor things, still more to be done. Thanks, John |
|
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 |
|
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: 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: 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 |
