Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
For example, many users call one of the following: ``` newPayload(ByteStreams.toByteArray(new FileInputStream(File))) newPayload(new FileInputStream(File)) ``` The former leaks a file descriptor and consumes extra memory while the latter disables repeatable payloads. Instead users should call the more optimal: ``` newPayload(Files.asByteSource(File)) ``` --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49499481
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
@aledsage wrote: > I also cleaned up some other deprecated code that seemed like quick wins. The > replacement for new StringPayload(value) is quite long winded (particularly > when you want to specify the charset)! > > Payloads.newByteSourcePayload(ByteSource.wrap(value.getBytes(Charset.forName("UTF-8"; The deprecated payload types generally have only minor notational advantages for tests; usually callers have larger inputs in either in `ByteSource` or `InputStream` forms. That being said, we could provide helper overrides to Payloads which take `byte[]` and `String` and automatically return `ByteSource` or provide some helper classes which extend `ByteSource`. However, I have observed many users suboptimally using the deprecated APIs, for example reading entire inputs instead of streaming inputs, so providing a narrower interface might nudge them to the more optimal uses. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49499408
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
Thanks for the cleanup, @aledsage! +1 - looks good to me, too! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49444198
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
Thanks @aledsage! I've done a quick search in the rest of downstream repos and there should not be other references to the removed method. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49407583
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
[jclouds » jclouds-labs #1310](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs/1310/) 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-labs/pull/69#issuecomment-49368296
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
[jclouds-labs-pull-requests #212](https://jclouds.ci.cloudbees.com/job/jclouds-labs-pull-requests/212/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49366736
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
[jclouds » jclouds-labs #1309](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs/1309/) 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-labs/pull/69#issuecomment-49366313
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
[jclouds-labs-pull-requests #211](https://jclouds.ci.cloudbees.com/job/jclouds-labs-pull-requests/211/) SUCCESS This pull request looks good --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49366300
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
Thanks @andreaturli @nacx - I've fixed the toString errors in other projects. I've commented on https://issues.apache.org/jira/browse/JCLOUDS-622 suggesting that we don't delete `Strings2#toString(InputSupplier)` method yet. I also cleaned up some other deprecated code that seemed like quick wins. The replacement for `new StringPayload(value)` is quite long winded (particularly when you want to specify the charset)! Payloads.newByteSourcePayload(ByteSource.wrap(value.getBytes(Charset.forName("UTF-8"; --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49364841
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
Yep, that will happen in all downstream repos. This is the bad thing about having several git repositories, changes like this have to wait in the downstream repos until the snapshots of the main one are populated. Thanks for taking care of this @aledsage! --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49332921
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
The error reported by the builders is now for cdmi, similar issue --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49332591
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
Lgtm :+1 Thanks @aledsage for taking care of it --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49331519
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
[jclouds-labs-pull-requests #210](https://jclouds.ci.cloudbees.com/job/jclouds-labs-pull-requests/210/) FAILURE Looks like there's a problem with this pull request --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/69#issuecomment-49328564
Re: [jclouds-labs] Fix DockerErrorHandler’s use of Strings2.toString (#69)
[jclouds » jclouds-labs #1307](https://buildhive.cloudbees.com/job/jclouds/job/jclouds-labs/1307/) FAILURE Looks like there's a problem with this pull request [(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-labs/pull/69#issuecomment-49328260