cloudfoundry/vcap-java-client — pull request #69 by gberche-orange (2013-08-22 10:10:13+00:00)
Title: Fixed regression: HTTP proxy config missing in OAuth 

Fixed regression introduced in edcb7a8 with does not propagate the HTTP proxy config to OAuth anymore

To test that the CF client is able to go through a proxy, we point the CC client to a broken url (by adding the suffix "injvmproxy.io" to the hostname). This broken url can only be resolved by going through an inJVM proxy which rewrites the URI. This can be disabled by setting the system property http.skipInJvmProxy to true. This inJvm proxy is implemented using jetty8 and its ProxyServlet. Jetty9 seems much improved but requires to upgrade to java7. It also records number of received requests which some tests can assert.

Limitations with this proxy-support testing method:
- the jetty8 ProxyServlet does not support proxy chaining. Therefore when the Junit test does not have direct access to the CC HTTPS API the test breaks with a 403.
- test infra in cloudfoundry-client-lib are lacking a logging framework. As a workaround system out traces were used instead.
- the CC client is following the URI returned in REST payload, that don't have the "injvmproxy.io" suffix to their hostname (e.g. https://login.run.pivotal.io/oauth/token). Therefore, some requests might be directly issued by the CC client skipping the proxy and still be unnoticed by tests. A possible solution would be to ensure all remote socket openings are only done by the inJvm proxy (i.e. jetty servlet) and never from the main junit thread. This seems possible fairly easily with using byteman: http://blog.javabenchmark.org/2013/04/fault-injection-in-your-junit-with.html

Please comment on this PR that my investment in automatically testing proxy-related regressions is of interest. In which case I would proceed with this and investigate solving the limitations above.