wpg-proxy-development — Developer Mailing List

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

[<ju...@ag...>]

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
>

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

[<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

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

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

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

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

[<ju...@ag...>]

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.

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

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

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

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

[<ju...@ag...>]

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

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

[<ju...@ag...>]

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
>

[Wpg-proxy-development] design details and impact on unit testing

[Alan M. <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ühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

Re: [Wpg-proxy-development] draft uml design

[Alan M. <a_j...@ya...>]

Hi John,

OK I have added you to my contact list on Skype so you
should be able to contact me.  I'll around a little
more tonight otherwise we will have to talk on Tuesday
since I doubt I can make it tomorrow night.

Thanks for the details below - I will go over these
carefully further before we continue discussions.

Atb,
A.

--- John Southerland <jo...@we...>
schrieb:

> Alan,
> I may not be reading it right, but you seem to have
> redesigned the entire
> package rather than documenting the package as it
> is.  The system is rather
> simple, perhaps too much so, but I don't want to
> deviate from that simple
> design unless absolutely positively necessary.  We
> currently have a system
> that is designed thusly, forgive my use of English
> rather than uml to
> describe this, I do not speak fluent uml and so I
> think better in English ;)
> 1. we have a Proxy object that opens a port and
> behaves as an http proxy,
> accepting connections on whatever port specified ie:
> 	Proxy p = new Proxy( new InetAddress(), 8080, 50);
> Then to manipulate requests and responses we have
> objects which implement
> the HttpMessageProcessor interface.  This would be
> how a user would, for
> instance, change the HttpMessage as appropriate to
> support some special use
> case, ie passing everything to yet another proxy via
> something like:
> public class ProxyMessageProcessor implements
> HttpMessageProcessor {
> 	private com.wpg.Util.Proxy proxy = null;
> 	public ProxyMessageProcessor( com.wpg.Util.Proxy
> proxy ) {
> this.proxy=proxy; }
> 	private Logger logger =
> Logger.getLogger(ProxyMessageProcessor.class);
> 	public boolean doContinue(HttpMessage input) {
> return true; }
> 	public boolean doSend(HttpMessage input) { return
> true; }
> 	public HttpMessage process( HttpMessage input ) {
> 		logger.debug("Start Line: "+ input.getStartLine()
> );
> 		HttpMessageRequest message = (HttpMessageRequest)
> input;
> 		logger.debug("Trying converting tohost to proxy");
> 		int port = message.getToPort();
> 		String newURI = (port==443?"https://":"http://") +
> message.getToHost() +(port==80 || port==443?"":":"+
> message.getToPort()) +
> message.getUri();
> 		try{
> 			message.setUri(newURI);
> 		} catch( java.net.URISyntaxException e ) {
> 			logger.error("Error setting uri to: "+ newURI +"
> Exception: "+ e, e);
> 		}
> 		message.setToHost(proxy.host);
> 		message.setToPort(proxy.port);
> 		if( !proxy.user.equals("") ) {
> 			HashMap headers = (HashMap) message.getHeaders();
> 			Vector header = new Vector();
> 			header.addElement(
> proxy.getEncodedAuthorization()
> );
> 			headers.put("proxy-authorization", header);
> 		}
> 		return message;
> 	}
> }
> 
> Then when a user wants to do something special with
> the requests or
> responses, as in log them or record them somehow
> they would implement the
> HttpMessageListener interface and have at it.
> The HttpMessageListener is defined at:
>
http://wpg-proxy.sourceforge.net/com/wpg/proxy/HttpMessageListener.html
> 
> The idea is to register these listeners and
> processors then for each
> connection run through them in the order registered.
>  This allows the proxy
> to be a filter, logger, protocol translator,
> anything.  As needed by the
> project/programmer.  I see several seperations of
> functionality in your
> model that I don't quite understand why you want to
> remove the HttpMessage
> and the HttpMessageRequest and HttpMessageResponse
> extended from it, that
> solves so many issues in such an elegant way for me
> as a programmer.  I
> would entertain adding or changing some of the calls
> in the listener and
> processor since that makes the most sense to me with
> the design in place,
> however I don't think we can simplify it to "init",
> "handle", and "abort"
> since under certain situations some data is
> available and some is not, we
> could reduce the listerner interface from currently
> three separate "failed"
> methods with different arguments to simple one with
> null arguments when
> unavailable, for instance just this:
> 	failed(HttpMessageResponse response,
> HttpMessageRequest request,
> java.lang.Exception exception)
> However the logic for the two received methods I
> still prefer, one is called
> when a request is received, the other when a
> response is received, perhaps
> we could rename them to "requestReceived" and
> "responseReceived" in that
> order?
> 
> As far as the way the proxy handles connections I do
> preffer the single
> Proxy class looping through a NIO handler, and would
> like to stay with that
> design.  I am not 100% sure from the uml what is
> meant by a
> "ProxyConnection" object or the "ProxyServer" being
> initialized with arrays
> of requestHandlers (which I translate to the current
> processors) and an
> array of responseHandlers (which we currently call
> listeners).  I would be
> willing to refactor those names into something more
> appropriate if they are
> confusing, but redesigning the way the system is
> called or used seems
> unnecissary.
> 
> Am I off the mark with any of this?  Does it make
> sense?  Do you see any way
> of adding SSL support without rewriting the entire
> library?
> Should we discuss via skype?  I have the client
> installed and registered a
> user JohnSoutherland5.
> Thanks, John
>  
> 
> -----Original Message-----
> From:
> wpg...@li...
>
[mailto:wpg...@li...]
> On Behalf Of
> Alan Moran
> Sent: Saturday, January 27, 2007 1:54 PM
> To: wpg...@li...
> Subject: Re: [Wpg-proxy-development] draft uml
> design
> 
> John,
> 
> Thanks for the reminder ! I have added a PNG to the
> SVN.
> 
> BTW: citing design is not my way of claiming that it
> is currently defective :) Just want to get ideas
> straight before we jump into more complicated issues
> and to make it easy for the unit testing etc.  I am
> adding to this design so will checkin more again
> tomorrow if I am ready by then.
> 
> Thanks,
> A.
> 
> --- John Southerland <jo...@we...>
> schrieb:
> 
> > Alan,
> > Can you create a pretty picture and send that out
> to
> > us UML challenged
> > people?
> > Also please note that you can fire up a proxy by
> > running the main method of
> > the Proxy class, I am currently using the version
> of
> > this code we are
> > dealing with in another program with 98%
> > reliability.
> > I'm very interested in seeing this UML design.
> > Thanks, John
> >  
> 
> 
> ---------------------------------------------------
> 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
> 
>
-------------------------------------------------------------------------
> 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
> 


---------------------------------------------------
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

Re: [Wpg-proxy-development] draft uml design

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

Alan,
I may not be reading it right, but you seem to have redesigned the entire
package rather than documenting the package as it is.  The system is rather
simple, perhaps too much so, but I don't want to deviate from that simple
design unless absolutely positively necessary.  We currently have a system
that is designed thusly, forgive my use of English rather than uml to
describe this, I do not speak fluent uml and so I think better in English ;)
1. we have a Proxy object that opens a port and behaves as an http proxy,
accepting connections on whatever port specified ie:
	Proxy p = new Proxy( new InetAddress(), 8080, 50);
Then to manipulate requests and responses we have objects which implement
the HttpMessageProcessor interface.  This would be how a user would, for
instance, change the HttpMessage as appropriate to support some special use
case, ie passing everything to yet another proxy via something like:
public class ProxyMessageProcessor implements HttpMessageProcessor {
	private com.wpg.Util.Proxy proxy = null;
	public ProxyMessageProcessor( com.wpg.Util.Proxy proxy ) {
this.proxy=proxy; }
	private Logger logger =
Logger.getLogger(ProxyMessageProcessor.class);
	public boolean doContinue(HttpMessage input) { return true; }
	public boolean doSend(HttpMessage input) { return true; }
	public HttpMessage process( HttpMessage input ) {
		logger.debug("Start Line: "+ input.getStartLine() );
		HttpMessageRequest message = (HttpMessageRequest) input;
		logger.debug("Trying converting tohost to proxy");
		int port = message.getToPort();
		String newURI = (port==443?"https://":"http://") +
message.getToHost() +(port==80 || port==443?"":":"+ message.getToPort()) +
message.getUri();
		try{
			message.setUri(newURI);
		} catch( java.net.URISyntaxException e ) {
			logger.error("Error setting uri to: "+ newURI +"
Exception: "+ e, e);
		}
		message.setToHost(proxy.host);
		message.setToPort(proxy.port);
		if( !proxy.user.equals("") ) {
			HashMap headers = (HashMap) message.getHeaders();
			Vector header = new Vector();
			header.addElement( proxy.getEncodedAuthorization()
);
			headers.put("proxy-authorization", header);
		}
		return message;
	}
}

Then when a user wants to do something special with the requests or
responses, as in log them or record them somehow they would implement the
HttpMessageListener interface and have at it.
The HttpMessageListener is defined at:
http://wpg-proxy.sourceforge.net/com/wpg/proxy/HttpMessageListener.html

The idea is to register these listeners and processors then for each
connection run through them in the order registered.  This allows the proxy
to be a filter, logger, protocol translator, anything.  As needed by the
project/programmer.  I see several seperations of functionality in your
model that I don't quite understand why you want to remove the HttpMessage
and the HttpMessageRequest and HttpMessageResponse extended from it, that
solves so many issues in such an elegant way for me as a programmer.  I
would entertain adding or changing some of the calls in the listener and
processor since that makes the most sense to me with the design in place,
however I don't think we can simplify it to "init", "handle", and "abort"
since under certain situations some data is available and some is not, we
could reduce the listerner interface from currently three separate "failed"
methods with different arguments to simple one with null arguments when
unavailable, for instance just this:
	failed(HttpMessageResponse response, HttpMessageRequest request,
java.lang.Exception exception)
However the logic for the two received methods I still prefer, one is called
when a request is received, the other when a response is received, perhaps
we could rename them to "requestReceived" and "responseReceived" in that
order?

As far as the way the proxy handles connections I do preffer the single
Proxy class looping through a NIO handler, and would like to stay with that
design.  I am not 100% sure from the uml what is meant by a
"ProxyConnection" object or the "ProxyServer" being initialized with arrays
of requestHandlers (which I translate to the current processors) and an
array of responseHandlers (which we currently call listeners).  I would be
willing to refactor those names into something more appropriate if they are
confusing, but redesigning the way the system is called or used seems
unnecissary.

Am I off the mark with any of this?  Does it make sense?  Do you see any way
of adding SSL support without rewriting the entire library?
Should we discuss via skype?  I have the client installed and registered a
user JohnSoutherland5.
Thanks, John
 

-----Original Message-----
From: wpg...@li...
[mailto:wpg...@li...] On Behalf Of
Alan Moran
Sent: Saturday, January 27, 2007 1:54 PM
To: wpg...@li...
Subject: Re: [Wpg-proxy-development] draft uml design

John,

Thanks for the reminder ! I have added a PNG to the
SVN.

BTW: citing design is not my way of claiming that it
is currently defective :) Just want to get ideas
straight before we jump into more complicated issues
and to make it easy for the unit testing etc.  I am
adding to this design so will checkin more again
tomorrow if I am ready by then.

Thanks,
A.

--- John Southerland <jo...@we...>
schrieb:

> Alan,
> Can you create a pretty picture and send that out to
> us UML challenged
> people?
> Also please note that you can fire up a proxy by
> running the main method of
> the Proxy class, I am currently using the version of
> this code we are
> dealing with in another program with 98%
> reliability.
> I'm very interested in seeing this UML design.
> Thanks, John
>  


---------------------------------------------------
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

-------------------------------------------------------------------------
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

Re: [Wpg-proxy-development] draft uml design

[Alan M. <a_j...@ya...>]

John,

Thanks for the reminder ! I have added a PNG to the
SVN.

BTW: citing design is not my way of claiming that it
is currently defective :) Just want to get ideas
straight before we jump into more complicated issues
and to make it easy for the unit testing etc.  I am
adding to this design so will checkin more again
tomorrow if I am ready by then.

Thanks,
A.

--- John Southerland <jo...@we...>
schrieb:

> Alan,
> Can you create a pretty picture and send that out to
> us UML challenged
> people?
> Also please note that you can fire up a proxy by
> running the main method of
> the Proxy class, I am currently using the version of
> this code we are
> dealing with in another program with 98%
> reliability.
> I'm very interested in seeing this UML design.
> Thanks, John
>  


---------------------------------------------------
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

Re: [Wpg-proxy-development] draft uml design

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

Alan,
Can you create a pretty picture and send that out to us UML challenged
people?
Also please note that you can fire up a proxy by running the main method =
of
the Proxy class, I am currently using the version of this code we are
dealing with in another program with 98% reliability.
I'm very interested in seeing this UML design.
Thanks, John
=20
=20
-----Original Message-----
From: wpg...@li...
[mailto:wpg...@li...] On Behalf =
Of
Alan Moran
Sent: Saturday, January 27, 2007 11:42 AM
To: wpg...@li...
Subject: [Wpg-proxy-development] draft uml design

All,

I have added a simple UML diagram to try to clarify
more precisely what I mentioned in previous emails.=20
In addition there are some design notes.  Right now
the emphasis is on the basic HTTP proxy and it is of
course still incomplete but we can fill in the details
over the coming days.

Based on what is already done it would be pretty easy
to get a first version proxy (for HTTP) up and
running.

hth,
A.

---------------------------------------------------
You can find my GPG key (a_j...@ya...) at
ETH PGP Keyserver: http://www.tik.ee.ethz.ch/~pgp/
---------------------------------------------------




=09
	=09
___________________________________________________________=20
Der fr=FChe Vogel f=E4ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! =
Mail:
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

[Wpg-proxy-development] draft uml design

[Alan M. <a_j...@ya...>]

All,

I have added a simple UML diagram to try to clarify
more precisely what I mentioned in previous emails. 
In addition there are some design notes.  Right now
the emphasis is on the basic HTTP proxy and it is of
course still incomplete but we can fill in the details
over the coming days.

Based on what is already done it would be pretty easy
to get a first version proxy (for HTTP) up and
running.

hth,
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

Re: [Wpg-proxy-development] project (re)structure

[Alan M. <a_j...@ya...>]

Hi John,
   
  Thank you for your understanding ! I appreciate that jumping in and doing a re-org can be a bit unnerving ! I had similar experience with Ivy at first but have since used it in a few projects and it has really grown on me :)
   
  At the moment I am completing the UML - I did plan to check it in yesterday but ended up having a long night at work so will return to it today when I get home.  At the moment as I am just considering design I have not implemented anything and I think that  I will pinch liberally from what you have already done so that the ideas will fall into place.  I will of course be more precise about what I mean by callback in the UML (I am also writing design notes too.)  We can then review, amend and generally play around with the design until we are all happy with it.
   
  I'll post again as soon as I have everything ready - thanks for your patience.
   
  Regards,
  A.

John Southerland <jo...@we...> schrieb:
  Alan,
I must admit to at first just sitting here shaking my head wondering why we
are going through all this, but it only took me four minutes to get ivy up
and running with your new build.xml and I sort of like it. This is a
growing experience for me, and I will sit back and wait to look at your UML
stuff. I have to admit never having gone through a UML design before, I
usually use the post-it note method of defining features and usage along
with my trusty wall. 

One thing I did notice, after reading your email from earlier again, you
want to use a callback mechanism rather than a registered class method? I
believe registering a class can also be implemented as a callback method, by
simply implementing the interface in a more broad class, just as is
sometimes done in SWING, using an interface and registering it as we are
allows us to leave the implementation up to the developer, and I prefer that
to having just a callback method, which I do not personally enjoy. I am
hoping you are using the UML design you are putting together to document how
the system currently is, rather than changing the design at the first
revision. Can you clarify what you meant by the callback method? I will
copy and paste it here as I see you did not send it to the mailing list:

"OK what I propose is that instead of the processor
approach we adopt a callback design using a template
method within the Proxy to do the high level stuff."

That is what confuses me, let me download and install skype as I have never
used it before either ;)
Thanks, John



-----Original Message-----
From: wpg...@li...
[mailto:wpg...@li...] On Behalf Of
Alan Moran
Sent: Tuesday, January 23, 2007 4:52 PM
To: wpg...@li...
Subject: [Wpg-proxy-development] project (re)structure

All,

I have made some reorganisation of the project
structure (the old stuff is still under version
control in case anyone thinks I've removed too much :)

First off you will need to install ivy
(http://incubator.apache.org/ivy/). Ivy is a neat
depedency manager that retrieves JARs for you from the
internet (which it stores in a local cache in your
home directory, see ~/.ivy dir) and places copies into
your project lib directory - this means that we need
only cite which JARs are required (see ivy.xml) and it
does the rest (its uses well-known public repositories
to get the JARs for you.) Since the JARs are cached
you can use ivy for all your other projects too
without having to download again. See the website for
further marketing fluff. I have added notes in
README.

To ensure Ant can work with Ivy you need to install
Ivy after downloading it and add the
~/.ivy/jars/ivy.jar to your CLASSPATH. Then to see
ivy at work update your wpg-proxy project and issue
"ant libs" and your lib directory will be magically
filled - note that you do not need to check in these
JARs. BTW to add a new JAR just reconfigure ivy.xml
and re-run the libs target. etc.

The new build.xml contains the usual targets with
"compile" (default) for our normal code and "test" for
unit test classes etc. See ant -p for details. Just
play around with the targets to see if I missed
anything.

I'll get back to the UML stuff now which is nearly
ready and have this checked in tomorrow.

Hope everything is understandable and the way we want
things - just let me know if there are any issues.

Thx,
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



---------------------------------------------------
You can find my GPG key (a_j...@ya...) at
ETH PGP Keyserver: http://www.tik.ee.ethz.ch/~pgp/
---------------------------------------------------
 		
---------------------------------
Yahoo! 360° – Bloggen und Leute treffen. Erstellen Sie jetzt Ihre eigene Seite – kostenlos!. 

Re: [Wpg-proxy-development] project (re)structure

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

Alan,
I must admit to at first just sitting here shaking my head wondering why we
are going through all this, but it only took me four minutes to get ivy up
and running with your new build.xml and I sort of like it.  This is a
growing experience for me, and I will sit back and wait to look at your UML
stuff.   I have to admit never having gone through a UML design before, I
usually use the post-it note method of defining features and usage along
with my trusty wall.  

One thing I did notice, after reading your email from earlier again, you
want to use a callback mechanism rather than a registered class method?  I
believe registering a class can also be implemented as a callback method, by
simply implementing the interface in a more broad class, just as is
sometimes done in SWING, using an interface and registering it as we are
allows us to leave the implementation up to the developer, and I prefer that
to having just a callback method, which I do not personally enjoy.  I am
hoping you are using the UML design you are putting together to document how
the system currently is, rather than changing the design at the first
revision.  Can you clarify what you meant by the callback method?  I will
copy and paste it here as I see you did not send it to the mailing list:

"OK what I propose is that instead of the processor
approach we adopt a callback design using a template
method within the Proxy to do the high level stuff."

That is what confuses me, let me download and install skype as I have never
used it before either ;)
Thanks, John

 
 
-----Original Message-----
From: wpg...@li...
[mailto:wpg...@li...] On Behalf Of
Alan Moran
Sent: Tuesday, January 23, 2007 4:52 PM
To: wpg...@li...
Subject: [Wpg-proxy-development] project (re)structure

All,

I have made some reorganisation of the project
structure (the old stuff is still under version
control in case anyone thinks I've removed too much :)

First off you will need to install ivy
(http://incubator.apache.org/ivy/).  Ivy is a neat
depedency manager that retrieves JARs for you from the
internet (which it stores in a local cache in your
home directory, see ~/.ivy dir) and places copies into
your project lib directory - this means that we need
only cite which JARs are required (see ivy.xml) and it
does the rest (its uses well-known public repositories
to get the JARs for you.)  Since the JARs are cached
you can use ivy for all your other projects too
without having to download again.  See the website for
further marketing fluff.  I have added notes in
README.

To ensure Ant can work with Ivy you need to install
Ivy after downloading it and add the
~/.ivy/jars/ivy.jar to your CLASSPATH.  Then to see
ivy at work update your wpg-proxy project and issue
"ant libs" and your lib directory will be magically
filled - note that you do not need to check in these
JARs.  BTW to add a new JAR just reconfigure ivy.xml
and re-run the libs target. etc.

The new build.xml contains the usual targets with
"compile" (default) for our normal code and "test" for
unit test classes etc.  See ant -p for details.  Just
play around with the targets to see if I missed
anything.

I'll get back to the UML stuff now which is nearly
ready and have this checked in tomorrow.

Hope everything is understandable and the way we want
things - just let me know if there are any issues.

Thx,
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

[Wpg-proxy-development] project (re)structure

[Alan M. <a_j...@ya...>]

All,

I have made some reorganisation of the project
structure (the old stuff is still under version
control in case anyone thinks I've removed too much :)

First off you will need to install ivy
(http://incubator.apache.org/ivy/).  Ivy is a neat
depedency manager that retrieves JARs for you from the
internet (which it stores in a local cache in your
home directory, see ~/.ivy dir) and places copies into
your project lib directory - this means that we need
only cite which JARs are required (see ivy.xml) and it
does the rest (its uses well-known public repositories
to get the JARs for you.)  Since the JARs are cached
you can use ivy for all your other projects too
without having to download again.  See the website for
further marketing fluff.  I have added notes in
README.

To ensure Ant can work with Ivy you need to install
Ivy after downloading it and add the
~/.ivy/jars/ivy.jar to your CLASSPATH.  Then to see
ivy at work update your wpg-proxy project and issue
"ant libs" and your lib directory will be magically
filled - note that you do not need to check in these
JARs.  BTW to add a new JAR just reconfigure ivy.xml
and re-run the libs target. etc.

The new build.xml contains the usual targets with
"compile" (default) for our normal code and "test" for
unit test classes etc.  See ant -p for details.  Just
play around with the targets to see if I missed
anything.

I'll get back to the UML stuff now which is nearly
ready and have this checked in tomorrow.

Hope everything is understandable and the way we want
things - just let me know if there are any issues.

Thx,
A.








		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Wpg-proxy-development] project structure

[Alan M. <a_j...@ya...>]

Hi Juan,

> This is not an issue for me as  I can locally work
> with a Netbeans project
> with files linking to a local copy of the
> repository, anyway I thought the
> current svn code didn't include any
> netbeans-specific file,  but I agree the
> it may be a bit too complex for our simple project.

OK that's fine by me - saw something net-beanish
somewhere but no worries, I have a straightforward
build.xml so will go ahead with that.  I'll check it
in once I have finished testing all targets.
 
> As you suggested in some previous mail, JUnit maybe
> a good candidate to test
> things like that. but why not going for some already
> developed  java http
> server? As we only need it for our own testing
> sounds reasonable to avoid
> debugging an http server...

Yes of course you are right! I'll look into your
suggestion and see if I can get my best test
infrastructure working. Junit is of course the right
thing for unit testing etc. I have added a separate
build tree to my build.xml for unit tests etc.
 
> Usage of callbacks  sounds like a good idea, I was
> also thinking about it
> but for filters
[snip]
> I'm looking for that UML...

...in that case I will create a UML directory in SVN
and checkin my diagrams - we can model from there -
I'll try get the details ironed out tomorrow.

atb,
A.


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Wpg-proxy-development] project structure

[<ju...@ag...>]

Ignore my last message, jetty(http://jetty.mortbay.org/) looks like a much
better (and supported) option.

2007/1/22, Juan Gonz=E1lez <ju...@ag...>:
>
> Re,
>
> I just found a lightweight http server that looks like an adequate start:
> http://pygmy-httpd.sourceforge.net/index.html
>
> i keep digging ...
>

Re: [Wpg-proxy-development] project structure

[<ju...@ag...>]

Re,

I just found a lightweight http server that looks like an adequate start:
http://pygmy-httpd.sourceforge.net/index.html

i keep digging ...

Re: [Wpg-proxy-development] project structure

[<ju...@ag...>]

Hi back,
  (scroll down for comments)

I have been going over the code and putting together
> ideas on how to structure the project so that we are
> clear on what needs doing.  I'd like therefore to make
> the following suggestions...apologies now for the
> longish post :)
>
> * can we keep the build mechanism simple, i.e., drop
> the Makefile etc. along with any tool specific
> materials (e.g., netbeans generated build files etc.)
> - this doesn't mean you can't use that sort of thing,
> just keep it to youself ;) i.e., don't check it in.  I
> have prepared a simple build file + properties etc.
> that does all the usual things (e.g., clean, compile,
> javadocs etc.) - I'll check this in (and do the other
> svn jobs) if no-one has an objection here....


This is not an issue for me as  I can locally work with a Netbeans project
with files linking to a local copy of the repository, anyway I thought the
current svn code didn't include any netbeans-specific file,  but I agree the
it may be a bit too complex for our simple project.

* could we not distribute depedencies with the project
> (!) - these are not our JARs so we should not be
> looking after them :) I recommend using ivy for
> depdendency injection, i.e., in the build.xml that I
> will check in there is a "cache" task that goes off
> and gets all the JARS for you and puts them into your
> lib directory - its _very_ simple and we do not have
> to think about JARs themselves (it even downloads the
> right version and manages conflicts etc.)


I didn't know about ivy but it sounds interesting, and if you already have a
working build.xml for that it's fine with me.

* I think we all need to be very clear about what the
> proxy does and does not do (later I'll post a comment
> about some SSL difficulties which we may have) -
> therefore I am just completing a test/server pair to
> simulate a HTTP client/server, we can then place our
> proxy in between the two and observe/test what happens
> etc.  I suggest we use/improve/amend this basic test
> infrastructure to make sure we can always test that it
> is working the way we want.  For now I will focus on
> HTTP - if we agree on details we can move to HTTPS
> later etc.


As you suggested in some previous mail, JUnit maybe a good candidate to test
things like that. but why not going for some already developed  java http
server? As we only need it for our own testing sounds reasonable to avoid
debugging an http server...

OK, and now to the design itself ;) I looked at the
> Proxy class and see how it is intended to work but
> think we could follow a few lessons from similar
> projects (and native proxies.) Therefore I'd like to
> suggest that we use the Proxy to implement a template
> method using callbacks (=sort of processors in the
> current design.)  This means that Proxy is an
> intermediate server that has a simple pubic interface
> that relays requests/responses.  Proxy is configured
> at instantiation with lists (e.g., arrays) of request
> and of response handlers (in each case a callback
> handler implements a certain interface) and does
> nothing but maintain state information and invoke the
> callbacks in configured order, i.e., it follows a
> well-defined handler cycle.


Usage of callbacks  sounds like a good idea, I was also thinking about it
but for filters

I'm writing up some UML to make these points precise
> but I think it is a recognisable way of doing it from
> a network programming point of view and should make
> implementation pretty easy.  There are of course other
> little details (failures via exception only,
> threading, etc. etc.) but I think if we agree on the
> big picture then I think we can sort out the little
> details later.


I'm looking for that UML...

BTW: I use Umbrello for UML - is that ok for everyone
> (I can always PNG output for discussion purposes.)


That's  OK for me (and Umbrello follows the omg specification so it should
be importable in any moden UML program)

OK, that's all for now - I'll follow this up with my
> PNG post and we can take it from there.  Feel free to
> feedback/comment etc. thus far.....
>

We'll speak later

[Wpg-proxy-development] project structure

[Alan M. <a_j...@ya...>]

All,

I have been going over the code and putting together
ideas on how to structure the project so that we are
clear on what needs doing.  I'd like therefore to make
the following suggestions...apologies now for the
longish post :)

* can we keep the build mechanism simple, i.e., drop
the Makefile etc. along with any tool specific
materials (e.g., netbeans generated build files etc.)
- this doesn't mean you can't use that sort of thing,
just keep it to youself ;) i.e., don't check it in.  I
have prepared a simple build file + properties etc.
that does all the usual things (e.g., clean, compile,
javadocs etc.) - I'll check this in (and do the other
svn jobs) if no-one has an objection here....

* could we not distribute depedencies with the project
(!) - these are not our JARs so we should not be
looking after them :) I recommend using ivy for
depdendency injection, i.e., in the build.xml that I
will check in there is a "cache" task that goes off
and gets all the JARS for you and puts them into your
lib directory - its _very_ simple and we do not have
to think about JARs themselves (it even downloads the
right version and manages conflicts etc.)

* I think we all need to be very clear about what the
proxy does and does not do (later I'll post a comment
about some SSL difficulties which we may have) -
therefore I am just completing a test/server pair to
simulate a HTTP client/server, we can then place our
proxy in between the two and observe/test what happens
etc.  I suggest we use/improve/amend this basic test
infrastructure to make sure we can always test that it
is working the way we want.  For now I will focus on
HTTP - if we agree on details we can move to HTTPS
later etc.

OK, and now to the design itself ;) I looked at the
Proxy class and see how it is intended to work but
think we could follow a few lessons from similar
projects (and native proxies.) Therefore I'd like to
suggest that we use the Proxy to implement a template
method using callbacks (=sort of processors in the
current design.)  This means that Proxy is an
intermediate server that has a simple pubic interface
that relays requests/responses.  Proxy is configured
at instantiation with lists (e.g., arrays) of request
and of response handlers (in each case a callback
handler implements a certain interface) and does
nothing but maintain state information and invoke the
callbacks in configured order, i.e., it follows a
well-defined handler cycle.

I'm writing up some UML to make these points precise
but I think it is a recognisable way of doing it from
a network programming point of view and should make
implementation pretty easy.  There are of course other
little details (failures via exception only,
threading, etc. etc.) but I think if we agree on the
big picture then I think we can sort out the little
details later.

BTW: I use Umbrello for UML - is that ok for everyone
(I can always PNG output for discussion purposes.)

OK, that's all for now - I'll follow this up with my
PNG post and we can take it from there.  Feel free to
feedback/comment etc. thus far.....

atb,
A.












		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [Wpg-proxy-development] code review

[<ju...@ag...>]

Great, i'll work on that this week and we'll discuss back next week.

See you

2007/1/17, Alan Moran <a_j...@ya...>:
>
> All,
>
> ..my last email seems to have got swallowed by the SMTP god so here is
> another attempt!
>
> I'd like to tackle Proxy as I have a few ideas here on refactoring that I
> can get done in the coming days (incl. how to fit in the SSL etc.)
>
> Juan, feel free to work away on the other things (e.g., license,
> formatting, enums etc.) and we can check again next week where we stand on
> everything - is that ok with you ?
>
> Regards,
> A.
>

Re: [Wpg-proxy-development] code review

[Alan M. <a_j...@ya...>]

All,
   
  ..my last email seems to have got swallowed by the SMTP god so here is another attempt!
   
  I'd like to tackle Proxy as I have a few ideas here on refactoring that I can get done in the coming days (incl. how to fit in the SSL etc.) 
   
  Juan, feel free to work away on the other things (e.g., license, formatting, enums etc.) and we can check again next week where we stand on everything - is that ok with you ?
   
  Regards,
A.

John Southerland <jo...@we...> schrieb:
        v\:* {behavior:url(#default#VML);}  o\:* {behavior:url(#default#VML);}  w\:* {behavior:url(#default#VML);}  .shape {behavior:url(#default#VML);}        st1\:*{behavior:url(#default#ieooui) }                Guys,
  That sounds good please go ahead and apply those changes, I am traveling until the 25th and my linux development laptop just lost it’s hard drive, so I am a little disconnected. L
  I can still ssh into my main system, but it is a slightly less accessible server.
  Thanks, John
     
    
---------------------------------
  
  From: wpg...@li... [mailto:wpg...@li...] On Behalf Of Juan González
Sent: Tuesday, January 16, 2007 11:36 AM
To: wpg...@li...
Subject: Re: [Wpg-proxy-development] code review

   
  Hi Alan,
   i'll add somethings to your thoughts:
        * the code is a bit hard to read in many places owing to formatting - would you have any objection if I ran the classes through GNU indent or similar ? If necessary we can add a svn hook to do that sort of thing automatically. 

    
I agree and I'm passing the code through netbeans indentation system and will upload it in a little while, also I think using 1,5 generics to get typesafe collections and use the new for loop to help making the code easier to read (and more robust). 

     
    * to make the licensing a bit clear I'd suggest that you place a license in the root directory and add a template to each Java file ( e.g., with a comment, distributed as per shipped license or similar) - I see you have gone for LGPL so we should adopt those conventions perhaps.

    
Just to agree on how to add this to the package, we should add something like this to each java file (I think there is no need to name each of us, ?): 

Java HTTP Proxy Library (wpg-proxy), 
  more info at http://wpg-proxy.sourceforge.net/
  
  This library is free software; you can redistribute it and/or
  
  

modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.
  
  This library is distributed in the hope that it will be useful,


  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  Lesser General Public License for more details.
  
  You should have received a copy of the GNU Lesser General Public


  License along with this library; if not, write to the Free Software
  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
   

  And also add a Licence.txt file to package root with the text from http://www.gnu.org/licenses/lgpl.txt
    * a small detail perhaps but I noticed the use of protected logger members (e.g., in HttpMessage) - I personally feel it would be better to use private (static) logger members in each class since the logger name is based on the java package hierarchy and a logger per class makes things more intuitive (and easier to configure) with the logger configuration.

    
I prefer private static loggers too 

     
    * finally the classes might benefit from a mild dose of refactoring (e.g., I think that Proxy is a bit too big and has inner classes within where delegation model might be more appropriate etc.) - I could go ahead and model this myself without changing any functionality but don't want to make you too nervous about what I'm doing here - shall we discuss this in more detail ? 

    
I would extract those classes to ease code readability and debugging, Proxy looks a bit ugly actually. Anyway, as you said in another mail we should work out some UML modelling to have at hand. 

Enums may also find their way in (for HEADER_*, methods of requests,etc), they might also help making the library more robust as they avoid programming missuses from the root (like passing conect in place of connect) and ease filter creation... 

      all the best,

    Alan.

    
 

   
    same,
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/
---------------------------------------------------
 		
---------------------------------
NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.

Re: [Wpg-proxy-development] code review

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

Guys,

That sounds good please go ahead and apply those changes, I am traveling
until the 25th and my linux development laptop just lost it=92s hard =
drive, so
I am a little disconnected. :-(

I can still ssh into my main system, but it is a slightly less =
accessible
server.

Thanks, John

=20

  _____ =20

From: wpg...@li...
[mailto:wpg...@li...] On Behalf =
Of
Juan Gonz=E1lez
Sent: Tuesday, January 16, 2007 11:36 AM
To: wpg...@li...
Subject: Re: [Wpg-proxy-development] code review

=20

Hi Alan,
   i'll add somethings to your thoughts:

* the code is a bit hard to read in many places owing to formatting - =
would
you have any objection if I ran the classes through GNU indent or =
similar ?
If necessary we can add a svn hook to do that sort of thing =
automatically.=20


I agree and I'm passing the code through netbeans indentation system and
will upload it in a little while, also I think using 1,5 generics to get
typesafe collections and use the new for loop to help making the code =
easier
to read (and more robust).=20

=20

* to make the licensing a bit clear I'd suggest that you place a license =
in
the root directory and add a template to each Java file ( e.g., with a
comment, distributed as per shipped license or similar) - I see you have
gone for LGPL so we should adopt those conventions perhaps.


Just to agree on how to add this to the package, we should add something
like this to each java file (I think there is no need to name each of =
us,
?):=20

Java HTTP Proxy Library (wpg-proxy),=20


more info at http://wpg-proxy.sourceforge.net/





This library is free software; you can redistribute it and/or






modify it under the terms of the GNU Lesser General Public


License as published by the Free Software Foundation; either


version 2.1 of the License, or (at your option) any later version.





This library is distributed in the hope that it will be useful,



but WITHOUT ANY WARRANTY; without even the implied warranty of


MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU


Lesser General Public License for more details.





You should have received a copy of the GNU Lesser General Public



License along with this library; if not, write to the Free Software


Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  =
02110-1301
USA

=20

And also add a Licence.txt file to package root with the text from
http://www.gnu.org/licenses/lgpl.txt

* a small detail perhaps but I noticed the use of protected logger =
members
(e.g., in HttpMessage) - I personally feel it would be better to use =
private
(static) logger members in each class since the logger name is based on =
the
java package hierarchy and a logger per class makes things more =
intuitive
(and easier to configure) with the logger configuration.


I prefer private static loggers too=20

=20

* finally the classes might benefit from a mild dose of refactoring =
(e.g., I
think that Proxy is a bit too big and has inner classes within where
delegation model might be more appropriate etc.) - I could go ahead and
model this myself without changing any functionality but don't want to =
make
you too nervous about what I'm doing here - shall we discuss this in =
more
detail ?=20


I would extract those classes to ease code readability and debugging, =
Proxy
looks a bit ugly actually. Anyway, as you said in another mail we should
work out some UML modelling to have at hand.=20

Enums may also find their way in (for HEADER_*, methods of =
requests,etc),
they might also help making the library more robust as they avoid
programming missuses from the root (like passing conect in place of =
connect)
and ease filter creation...=20

all the best,

Alan.


=20

=20

same,
Juan.

Re: [Wpg-proxy-development] code review

[<ju...@ag...>]

Hi Alan,
   i'll add somethings to your thoughts:

* the code is a bit hard to read in many places owing to formatting - would
> you have any objection if I ran the classes through GNU indent or similar ?
> If necessary we can add a svn hook to do that sort of thing automatically.
>

I agree and I'm passing the code through netbeans indentation system and
will upload it in a little while, also I think using 1,5 generics to get
typesafe collections and use the new for loop to help making the code easier
to read (and more robust).

* to make the licensing a bit clear I'd suggest that you place a license in
> the root directory and add a template to each Java file (e.g., with a
> comment, distributed as per shipped license or similar) - I see you have
> gone for LGPL so we should adopt those conventions perhaps.
>

Just to agree on how to add this to the package, we should add something
like this to each java file (I think there is no need to name each of us,
?):

Java HTTP Proxy Library (wpg-proxy),
more info at http://wpg-proxy.sourceforge.net/

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA


And also add a Licence.txt file to package root with the text from
http://www.gnu.org/licenses/lgpl.txt

* a small detail perhaps but I noticed the use of protected logger members (
> e.g., in HttpMessage) - I personally feel it would be better to use
> private (static) logger members in each class since the logger name is based
> on the java package hierarchy and a logger per class makes things more
> intuitive (and easier to configure) with the logger configuration.
>

I prefer private static loggers too

* finally the classes might benefit from a mild dose of refactoring (e.g., I
> think that Proxy is a bit too big and has inner classes within where
> delegation model might be more appropriate etc.) - I could go ahead and
> model this myself without changing any functionality but don't want to make
> you too nervous about what I'm doing here - shall we discuss this in more
> detail ?
>

I would extract those classes to ease code readability and debugging, Proxy
looks a bit ugly actually. Anyway, as you said in another mail we should
work out some UML modelling to have at hand.

Enums may also find their way in (for HEADER_*, methods of requests,etc),
they might also help making the library more robust as they avoid
programming missuses from the root (like passing conect in place of connect)
and ease filter creation...

all the best,
> Alan.
>



same,
Juan.