> @@ -85,12 +85,19 @@ protected static MockWebServer mockWebServer(Dispatcher
> dispatcher) throws IOExc
> * Creates a test api for the given class and URL.
> */
> protected T api(Class apiClass, String url) {
> + return api(apiClass, url, createConnectionModule());
> + }
> +
> @@ -85,12 +85,19 @@ protected static MockWebServer mockWebServer(Dispatcher
> dispatcher) throws IOExc
> * Creates a test api for the given class and URL.
> */
> protected T api(Class apiClass, String url) {
> + return api(apiClass, url, createConnectionModule());
> + }
> +
> @@ -85,12 +85,19 @@ protected static MockWebServer mockWebServer(Dispatcher
> dispatcher) throws IOExc
> * Creates a test api for the given class and URL.
> */
> protected T api(Class apiClass, String url) {
> + return api(apiClass, url, createConnectionModule());
> + }
> +
Thanks, @nacx!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomment-65290826
Big +1
Thanks @nacx I'll test it asap with Docker!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomment-65272200
Squashed and pushed to master as
[958d09e](https://git-wip-us.apache.org/repos/asf?p=jclouds.git;a=commitdiff;h=958d09ecbd2956f6cedfadfa2c67040c386bd105).
Thanks for the reviews and feedback!
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuec
[jclouds » jclouds
#1972](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1972/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomme
That makes sense. I'll change the PR to use the supplier approach and fix the
javadocs. If someone want to use this feature for anything else, PRs are
welcome :)
Thanks for your feedback @adriancole. It is very much appreciated!
---
Reply to this email directly or view it on GitHub:
https://git
Again, my suggestion is to limit this to api config, not general purpose
settings such as timeouts, and also to not document this as a "user"
feature rather an internal hook for api writing.
It gets complicated otherwise, as you've mentioned, and the primary goal is
to address tls settings for doc
I thought about where to hook the user config and chose to put it at the end,
to make sure it won't be changes by jclouds. This will also help changing and
improving the driver without worrying about breaking user customizations.
I like the supplier approach, but there are properties, such as ti
> What if instead, OkHttpClientProvider used OkHttpClientSupplier first
I guess all we would have to ensure in that case is that we don't stomp on any
changes/configuration settings the user has made in a custom
`OkHttpClientSupplier`. Nice!
Thanks, @adriancole!
---
Reply to this email directl
@nacx so I didn't think of an easier way out before.
So, right now, there's an okhttp client provider, and this news up an
OkHttpClient. As a last step, it configures it.
What if instead, OkHttpClientProvider used OkHttpClientSupplier first, as
opposed to ConfigureOkHttpClient last? The interfa
[jclouds » jclouds
#1971](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1971/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomme
I have commented many times about ssl context, that it isn't actually
exposed in all http drivers, and that we should beware of attempting to own
ssl configuration. Ex as mentioned before the optional injection for
default ssl context is only labs and not in apachehc.
Http drivers should be a gate
@nacx: Just some minor comments from me. As regards the question you and
@adriancole have been discussing: I like the suggestion of saying "we'll
configure safe stuff for the provider you choose, but if you want to make
arbitrary other configuration changes to the HTTP client, here you go!"
Thi
>private final HostnameVerifier verifier;
>private final Supplier untrustedSSLContextProvider;
>private final HttpUtils utils;
> + private final List connectionSpecs;
> +
> + @Inject(optional = true)
> + private Supplier sslContextSupplier;
Recalling @adrianc
> @@ -85,12 +85,19 @@ protected static MockWebServer mockWebServer(Dispatcher
> dispatcher) throws IOExc
> * Creates a test api for the given class and URL.
> */
> protected T api(Class apiClass, String url) {
> + return api(apiClass, url, createConnectionModule());
> + }
> +
> @@ -50,6 +50,11 @@
>test
>
>
> +com.google.inject.extensions
> +guice-multibindings
> +3.0
[minor] Indent. We can clean this up during the merge.
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619/files#
[jclouds-pull-requests
#1427](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1427/) SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomment-65003472
[jclouds » jclouds
#1968](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1968/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomme
I've updated the PR to use multi bindings to provide the connection specs.
Regarding the `Supplier` optional injection, my main concern about
providing a callback and removing the supplier is that the supplier approach is
used in the other drivers. I agree that it would be more flexible to provi
>private final HostnameVerifier verifier;
>private final Supplier untrustedSSLContextProvider;
>private final HttpUtils utils;
>
> + @Inject(optional = true)
> + private Supplier sslContextSupplier;
> +
> + @Inject(optional = true)
Oh, that makes sense. Thi
suggestion on how to rejig out of needing to use guice inheritance.
sidebar..
Another way, which could avoid constantly punching holes could be to allow the
user a callback to customize the base okhttp client.
Ex.
```java
interface ConfigureOkHttpClient {
/** Use this to customize the bas
>private final HostnameVerifier verifier;
>private final Supplier untrustedSSLContextProvider;
>private final HttpUtils utils;
>
> + @Inject(optional = true)
> + private Supplier sslContextSupplier;
> +
> + @Inject(optional = true)
optional injection is som
[jclouds » jclouds
#1966](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1966/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomme
[jclouds-pull-requests
#1424](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1424/) SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomment-64969406
[jclouds » jclouds
#1965](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1965/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomme
[jclouds-pull-requests
#1425](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1425/) SUCCESS
This pull request looks good
---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/619#issuecomment-64968750
Makes the ConnectionSpecs injectable so providers and users can provide a
custom one.
This should also fix
[JCLOUDS-753](https://issues.apache.org/jira/browse/JCLOUDS-753), as the change
provides a clean way of setting the supported TLS protocols.
/cc @adriancole @andreaturli
You can merge thi
29 matches
Mail list logo
