Re: [Wpg-proxy-development] design details and impact on unittesting

[John S. <jo...@we...>]

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