Jenkins build is back to normal : jclouds » jclouds s3 api #3623

2017-08-06 Thread jenkins-no-reply 
See

Jenkins build is back to normal : jclouds #3623

2017-08-06 Thread jenkins-no-reply 
See

Build failed in Jenkins: jclouds #3622

2017-08-06 Thread jenkins-no-reply 
See 


Changes:

[Andrew Gaul] Allow lastModified to be null

--
[...truncated 2.00 MB...]
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check (default) on 
project s3: You have 1 Checkstyle violation. -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check (default) on 
project s3: You have 1 Checkstyle violation.
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at 
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:139)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.MojoFailureException: You have 1 Checkstyle 
violation.
at 
org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:580)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 30 more
[ERROR] 
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :s3
[JENKINS] Archiving 
 to 
org.apache.jclouds/jclouds-resources/2.1.0-SNAPSHOT/jclouds-resources-2.1.0-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.jclouds/jclouds-resources/2.1.0-20170807.005037-102/jclouds-resources-2.1.0-20170807.005037-102.jar
[JENKINS] Archiving 

 to 
org.apache.jclouds/jclouds-resources/2.1.0-20170807.005037-102/jclouds-resources-2.1.0-20170807.005037-102-tests.jar
[JENKINS] Archiving 

 to 
org.apache.jclouds/jclouds-resources/2.1.0-20170807.005037-102/jclouds-resources-2.1.0-20170807.005037-102-sources.jar
[JENKINS] Archiving

Build failed in Jenkins: jclouds » jclouds s3 api #3622

2017-08-06 Thread jenkins-no-reply 
See 


--
[...truncated 49.04 KB...]
[pool-18-thread-3] Test 
testNullOnUnmatchedRegion(org.jclouds.s3.blobstore.functions.LocationFromBucketNameTest)
 succeeded: 1ms
Test suite progress: tests succeeded: 141, failed: 0, skipped: 0.
Starting test 
testAmzEtagStillParsesToMD5AndDoesntMistakeAmzEtagForUserMetadata(org.jclouds.s3.functions.ParseObjectMetadataFromHeadersTest)
Starting test 
testMultipartDoesntAttemptToParseETagIntoMD5(org.jclouds.s3.functions.ParseObjectMetadataFromHeadersTest)
Starting test 
testNormalParsesETagIntoMD5AndMetadataHeaders(org.jclouds.s3.functions.ParseObjectMetadataFromHeadersTest)
[pool-19-thread-2] Test 
testMultipartDoesntAttemptToParseETagIntoMD5(org.jclouds.s3.functions.ParseObjectMetadataFromHeadersTest)
 succeeded: 1ms
Test suite progress: tests succeeded: 142, failed: 0, skipped: 0.
[pool-19-thread-1] Test 
testAmzEtagStillParsesToMD5AndDoesntMistakeAmzEtagForUserMetadata(org.jclouds.s3.functions.ParseObjectMetadataFromHeadersTest)
 succeeded: 1ms
Test suite progress: tests succeeded: 143, failed: 0, skipped: 0.
[pool-19-thread-3] Test 
testNormalParsesETagIntoMD5AndMetadataHeaders(org.jclouds.s3.functions.ParseObjectMetadataFromHeadersTest)
 succeeded: 0ms
Test suite progress: tests succeeded: 144, failed: 0, skipped: 0.
Starting test 
test(org.jclouds.s3.functions.UploadIdFromHttpResponseViaRegexTest)
[pool-20-thread-1] Test 
test(org.jclouds.s3.functions.UploadIdFromHttpResponseViaRegexTest) succeeded: 
2ms
Test suite progress: tests succeeded: 145, failed: 0, skipped: 0.
Starting test test(org.jclouds.s3.functions.ETagFromHttpResponseViaRegexTest)
[pool-21-thread-1] Test 
test(org.jclouds.s3.functions.ETagFromHttpResponseViaRegexTest) succeeded: 1ms
Test suite progress: tests succeeded: 146, failed: 0, skipped: 0.
Starting test test(org.jclouds.s3.functions.GetRegionForBucketTest)
[pool-22-thread-1] Test test(org.jclouds.s3.functions.GetRegionForBucketTest) 
succeeded: 1ms
Test suite progress: tests succeeded: 147, failed: 0, skipped: 0.
Starting test 
testGracefulOnException(org.jclouds.s3.functions.GetRegionForBucketTest)
[pool-22-thread-2] Test 
testGracefulOnException(org.jclouds.s3.functions.GetRegionForBucketTest) 
succeeded: 0ms
Test suite progress: tests succeeded: 148, failed: 0, skipped: 0.
Starting test 
testGracefulOnException(org.jclouds.s3.functions.GetRegionForBucketTest)
[pool-22-thread-2] Test 
testGracefulOnException(org.jclouds.s3.functions.GetRegionForBucketTest) 
succeeded: 1ms
Test suite progress: tests succeeded: 149, failed: 0, skipped: 0.
Starting test 
testGracefulOnException(org.jclouds.s3.functions.GetRegionForBucketTest)
[pool-22-thread-2] Test 
testGracefulOnException(org.jclouds.s3.functions.GetRegionForBucketTest) 
succeeded: 0ms
Test suite progress: tests succeeded: 150, failed: 0, skipped: 0.
Starting test 
testBucketExistsReturnsTrueOn200AndFalseOn404(org.jclouds.s3.PathBasedS3ClientExpectTest)
Starting test 
testPutBucketReturnsTrueOn200(org.jclouds.s3.PathBasedS3ClientExpectTest)
Starting test 
testPutObjectReturnsETagOn200(org.jclouds.s3.PathBasedS3ClientExpectTest)
Aug 06, 2017 8:58:00 PM org.jclouds.rest.internal.BaseRestApiExpectTest 
createInjector
WARNING: provider [mock] is not setup as 
META-INF/services/org.jclouds.apis.ApiMetadata or 
META-INF/services/org.jclouds.providers.ProviderMetadata
Aug 06, 2017 8:58:00 PM org.jclouds.rest.internal.BaseRestApiExpectTest 
createInjector
WARNING: provider [mock] is not setup as 
META-INF/services/org.jclouds.apis.ApiMetadata or 
META-INF/services/org.jclouds.providers.ProviderMetadata
Aug 06, 2017 8:58:00 PM org.jclouds.rest.internal.BaseRestApiExpectTest 
createInjector
WARNING: provider [mock] is not setup as 
META-INF/services/org.jclouds.apis.ApiMetadata or 
META-INF/services/org.jclouds.providers.ProviderMetadata
[pool-23-thread-3] Test 
testPutObjectReturnsETagOn200(org.jclouds.s3.PathBasedS3ClientExpectTest) 
succeeded: 50ms
Test suite progress: tests succeeded: 151, failed: 0, skipped: 0.
Aug 06, 2017 8:58:00 PM org.jclouds.rest.internal.BaseRestApiExpectTest 
createInjector
WARNING: provider [mock] is not setup as 
META-INF/services/org.jclouds.apis.ApiMetadata or 
META-INF/services/org.jclouds.providers.ProviderMetadata
[pool-23-thread-2] Test 
testPutBucketReturnsTrueOn200(org.jclouds.s3.PathBasedS3ClientExpectTest) 
succeeded: 57ms
Test suite progress: tests succeeded: 152, failed: 0, skipped: 0.
[pool-23-thread-1] Test 
testBucketExistsReturnsTrueOn200AndFalseOn404(org.jclouds.s3.PathBasedS3ClientExpectTest)
 succeeded: 102ms
Test suite progress: tests succeeded: 153, failed: 0, skipped: 0.
Starting test testCanParseCopyObjectResult(org.jclouds.s3.xml.S3ParserTest)
[pool-25-thread-1] Test 
testCanParseCopyObjectResult(org.jclouds.s3.xml.S3ParserTest) succeeded: 5ms
Test suite progress: tests succeeded: 154, failed: 0, skipped: 0.

[jira] [Commented] (JCLOUDS-902) GCS temporary signed URLs

2017-08-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115964#comment-16115964
 ] 

ASF subversion and git services commented on JCLOUDS-902:
-

Commit 5cbefccf969fe8ab74b7111aedd486a4304ae903 in jclouds's branch 
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=5cbefcc ]

JCLOUDS-902: Enable GCS access integration tests

Enabled by request signing.


> GCS temporary signed URLs
> -
>
> Key: JCLOUDS-902
> URL: https://issues.apache.org/jira/browse/JCLOUDS-902
> Project: jclouds
>  Issue Type: New Feature
>  Components: jclouds-blobstore, jclouds-labs-google
>Affects Versions: 1.9.0
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
> Fix For: 2.1.0, 2.0.2
>
>
> All other jclouds providers support temporary signed URLs and Google also 
> provides support for this:
> https://cloud.google.com/storage/docs/gsutil/commands/signurl
> jclouds should add support for this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [jclouds/jclouds] JCLOUDS-1322: Remove Expect header for requests with empty body (#1120)

2017-08-06 Thread Andrew Gaul 
Thanks for investigating the failure which I addressed in 
9e73bbec16cbf91c5f228d4c3ae99c6c526081f8.  You will need to rebase your commit 
since I included your integration tests to validate my fix.  I guess this is 
fine to merge although I still do not understand why you are so motivated to 
optimize an uncommon path.  I have asked this twice before and did not received 
an answer -- which benchmark do you have which shows that this is a performance 
issue?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1120#issuecomment-320532517

[jira] [Resolved] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread Andrew Gaul (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1327.
--
   Resolution: Fixed
Fix Version/s: 2.0.3
   2.1.0

Sorry I did not understand the failure earlier.  I pushed your integration 
tests from JCLOUDS-1322 with the fix.

> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Affects Versions: 2.0.2
>Reporter: Chaithanya Ganta
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
> Fix For: 2.1.0, 2.0.3
>
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> {noformat}
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread Andrew Gaul (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul updated JCLOUDS-1327:
-
Affects Version/s: 2.0.2

> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Affects Versions: 2.0.2
>Reporter: Chaithanya Ganta
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> {noformat}
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCLOUDS-912) GCS uploads with InputStream payloads are not working

2017-08-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115931#comment-16115931
 ] 

ASF subversion and git services commented on JCLOUDS-912:
-

Commit 69866189d73449aeb5b698e30959b5fcfaeab0cc in jclouds-labs-google's branch 
refs/heads/2.0.x from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=6986618 ]

JCLOUDS-1327: Do not try GCS MPU if length is zero

References JCLOUDS-912.


> GCS uploads with InputStream payloads are not working
> -
>
> Key: JCLOUDS-912
> URL: https://issues.apache.org/jira/browse/JCLOUDS-912
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore, jclouds-labs-google
>Affects Versions: 1.9.0
> Environment: Ubuntu 14.04.2 LTS 64-bit
> java version "1.7.0_76"
> Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
>Reporter: Ben Piper
>  Labels: google-cloud-storage
>
> It seems that Payloads based on an InputStream are not currently working with 
> the google-cloud-storage API, either with simpleUpload or multipartUpload.  
> The stream is getting closed before a single byte is read for transmission to 
> the GCS endpoint.
> The payload in the request object is first initialised when 
> GeneratedHttpRequest.Builder.build is called in 
> RestAnnotationProcessor.apply, and then setPayload is later called on the 
> HttpRequest object by MultipartUploadBinder (or UploadBinder in the case of 
> simpleUpload), causing the originally supplied InputStream to be closed.
> The setPayload call in UploadBinder.bindToRequest seems redundant, if the 
> payload has already been set when the request object was built.  
> MultipartUploadBinder.bindToRequest wraps the original payload in a 
> MultipartForm, but the stream in the media part will still end up being 
> closed by the setPayload call.  At face value, it doesn't seem like 
> MapBinder.bindToRequest is an appropriate place to call setPayload unless it 
> is legitimate to completely replace the original payload (rather than wrap 
> it) - or at least if it has to mutate the payload property of the request 
> object, then it needs some way of doing it that doesn't result in the 
> originally supplied Payload being 'released'.
> The simplest way of reproducing this is probably just to add a new 
> integration test, similar to ObjectApiLiveTest.testMultipartJpegUpload, but 
> using a FileInputStream based Payload rather than a ByteSource one.
> Relevant portion of stack trace is below.
> {code}
> Caused by: java.io.IOException: Stream already closed
>   at org.jvnet.mimepull.DataHead$ReadMultiStream.fetch(DataHead.java:248) 
> ~[mimepull-1.9.3.jar:1.9.3]
>   at org.jvnet.mimepull.DataHead$ReadMultiStream.read(DataHead.java:219) 
> ~[mimepull-1.9.3.jar:1.9.3]
>   at java.io.SequenceInputStream.read(SequenceInputStream.java:208) 
> ~[na:1.7.0_76]
>   at java.io.SequenceInputStream.read(SequenceInputStream.java:211) 
> ~[na:1.7.0_76]
>   at java.io.InputStream.read(InputStream.java:101) ~[na:1.7.0_76]
>   at com.google.common.io.ByteStreams.copy(ByteStreams.java:175) 
> ~[guava-16.0.1.jar:na]
>   at 
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.writePayloadToConnection(JavaUrlHttpCommandExecutorService.java:297)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:170)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:64)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:91)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90) 
> ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73) 
> ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44) 
> ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
>  ~[guava-16.0.1.jar:na]
>   at com.sun.proxy.$Proxy120.multipartUpload(Unknown Source) ~[na:na]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115930#comment-16115930
 ] 

ASF subversion and git services commented on JCLOUDS-1327:
--

Commit 69866189d73449aeb5b698e30959b5fcfaeab0cc in jclouds-labs-google's branch 
refs/heads/2.0.x from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds-labs-google.git;h=6986618 ]

JCLOUDS-1327: Do not try GCS MPU if length is zero

References JCLOUDS-912.


> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115928#comment-16115928
 ] 

ASF subversion and git services commented on JCLOUDS-1327:
--

Commit 5e9743a226c7fbec4a0bdcbb169c8c612925cdb9 in jclouds's branch 
refs/heads/2.0.x from [~chaitanya.n...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=5e9743a ]

JCLOUDS-1327: Add tests for zero-length blobs


> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115926#comment-16115926
 ] 

ASF subversion and git services commented on JCLOUDS-1327:
--

Commit 9e73bbec16cbf91c5f228d4c3ae99c6c526081f8 in jclouds's branch 
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=9e73bbe ]

JCLOUDS-1327: Do not try GCS MPU if length is zero

References JCLOUDS-912.


> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCLOUDS-912) GCS uploads with InputStream payloads are not working

2017-08-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115927#comment-16115927
 ] 

ASF subversion and git services commented on JCLOUDS-912:
-

Commit 9e73bbec16cbf91c5f228d4c3ae99c6c526081f8 in jclouds's branch 
refs/heads/master from [~gaul]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=9e73bbe ]

JCLOUDS-1327: Do not try GCS MPU if length is zero

References JCLOUDS-912.


> GCS uploads with InputStream payloads are not working
> -
>
> Key: JCLOUDS-912
> URL: https://issues.apache.org/jira/browse/JCLOUDS-912
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore, jclouds-labs-google
>Affects Versions: 1.9.0
> Environment: Ubuntu 14.04.2 LTS 64-bit
> java version "1.7.0_76"
> Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
>Reporter: Ben Piper
>  Labels: google-cloud-storage
>
> It seems that Payloads based on an InputStream are not currently working with 
> the google-cloud-storage API, either with simpleUpload or multipartUpload.  
> The stream is getting closed before a single byte is read for transmission to 
> the GCS endpoint.
> The payload in the request object is first initialised when 
> GeneratedHttpRequest.Builder.build is called in 
> RestAnnotationProcessor.apply, and then setPayload is later called on the 
> HttpRequest object by MultipartUploadBinder (or UploadBinder in the case of 
> simpleUpload), causing the originally supplied InputStream to be closed.
> The setPayload call in UploadBinder.bindToRequest seems redundant, if the 
> payload has already been set when the request object was built.  
> MultipartUploadBinder.bindToRequest wraps the original payload in a 
> MultipartForm, but the stream in the media part will still end up being 
> closed by the setPayload call.  At face value, it doesn't seem like 
> MapBinder.bindToRequest is an appropriate place to call setPayload unless it 
> is legitimate to completely replace the original payload (rather than wrap 
> it) - or at least if it has to mutate the payload property of the request 
> object, then it needs some way of doing it that doesn't result in the 
> originally supplied Payload being 'released'.
> The simplest way of reproducing this is probably just to add a new 
> integration test, similar to ObjectApiLiveTest.testMultipartJpegUpload, but 
> using a FileInputStream based Payload rather than a ByteSource one.
> Relevant portion of stack trace is below.
> {code}
> Caused by: java.io.IOException: Stream already closed
>   at org.jvnet.mimepull.DataHead$ReadMultiStream.fetch(DataHead.java:248) 
> ~[mimepull-1.9.3.jar:1.9.3]
>   at org.jvnet.mimepull.DataHead$ReadMultiStream.read(DataHead.java:219) 
> ~[mimepull-1.9.3.jar:1.9.3]
>   at java.io.SequenceInputStream.read(SequenceInputStream.java:208) 
> ~[na:1.7.0_76]
>   at java.io.SequenceInputStream.read(SequenceInputStream.java:211) 
> ~[na:1.7.0_76]
>   at java.io.InputStream.read(InputStream.java:101) ~[na:1.7.0_76]
>   at com.google.common.io.ByteStreams.copy(ByteStreams.java:175) 
> ~[guava-16.0.1.jar:na]
>   at 
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.writePayloadToConnection(JavaUrlHttpCommandExecutorService.java:297)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:170)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:64)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:91)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:90) 
> ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73) 
> ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44) 
> ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
>  ~[jclouds-core-1.9.0.jar:1.9.0]
>   at 
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
>  ~[guava-16.0.1.jar:na]
>   at com.sun.proxy.$Proxy120.multipartUpload(Unknown Source) ~[na:na]
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115925#comment-16115925
 ] 

ASF subversion and git services commented on JCLOUDS-1327:
--

Commit d6038487f7d4256f73dd089c9bc8d307fbae0aff in jclouds's branch 
refs/heads/master from [~chaitanya.n...@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=jclouds.git;h=d603848 ]

JCLOUDS-1327: Add tests for zero-length blobs


> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread Andrew Gaul (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul reopened JCLOUDS-1327:
--
  Assignee: Andrew Gaul

> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>Assignee: Andrew Gaul
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [jclouds/jclouds] JCLOUDS-1322: Remove Expect header for requests with empty body (#1120)

2017-08-06 Thread Chaithanya Ganta 
@andrewgaul This PR doesn't introduce any regression. `putBlob` with 
zero-length inputstream is failing before as well on google-cloud. The thing is 
we don't have a test case for that scenario before, so you didn't see any test 
failure.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1120#issuecomment-320528041

[jira] [Commented] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread Chaithanya Ganta (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115909#comment-16115909
 ] 

Chaithanya Ganta commented on JCLOUDS-1327:
---

[~argaul] This issue has nothing to do with the proposed change in 
https://github.com/jclouds/jclouds/pull/1120. There is actually a bug in 
BaseBlobStore.putMultipartBlob which causes this issue.

> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [jclouds/jclouds] JCLOUDS-1322: Remove Expect header for requests with empty body (#1120)

2017-08-06 Thread Andrew Gaul 
To clear up any confusion, the proposed change introduces a regression in 
google-cloud-storage and must be addressed before merging.  Previously 
zero-byte writes succeeded and with this pull request they fail.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1120#issuecomment-320527190

[jira] [Resolved] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread Andrew Gaul (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul resolved JCLOUDS-1327.
--
Resolution: Invalid

Marking invalid since this is an issue with a proposed change, not a merged 
change:

https://github.com/jclouds/jclouds/pull/1120

> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread Andrew Gaul (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul updated JCLOUDS-1327:
-
Labels: google-cloud-storage  (was: )

> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCLOUDS-1327) putBlob with zero length Inputstream is failing on google-cloud-storage

2017-08-06 Thread Andrew Gaul (JIRA) 

 [ 
https://issues.apache.org/jira/browse/JCLOUDS-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Gaul updated JCLOUDS-1327:
-
Affects Version/s: (was: 2.0.2)

> putBlob with zero length Inputstream is failing on google-cloud-storage
> ---
>
> Key: JCLOUDS-1327
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1327
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-blobstore
>Reporter: Chaithanya Ganta
>  Labels: google-cloud-storage
>
> putBlob with zero length Inputstream is failing on google-cloud-storage with
> org.jclouds.http.HttpResponseException: command: POST 
> https://www.googleapis.com/storage/v1/b/gaul-blobstore3/o/multipart-upload/compose
>  HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
>  "error": {
>   "errors": [
>{
> "domain": "global",
> "reason": "required",
> "message": "You must provide at least one source component."
>}
>   ],
>   "code": 400,
>   "message": "You must provide at least one source component."
>  }
> }
> ]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCLOUDS-1323) Openstack: security group format changed

2017-08-06 Thread Andrea Turli (JIRA) 

[ 
https://issues.apache.org/jira/browse/JCLOUDS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115827#comment-16115827
 ] 

Andrea Turli commented on JCLOUDS-1323:
---

https://github.com/jclouds/jclouds/pull/1128

> Openstack: security group format changed
> 
>
> Key: JCLOUDS-1323
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1323
> Project: jclouds
>  Issue Type: Bug
>  Components: jclouds-compute
>Affects Versions: 2.1.0
>Reporter: Svetoslav Neykov
>  Labels: openstack-nova
>
> [PR #1117|https://github.com/jclouds/jclouds/pull/1117] changes how security 
> groups for openstack-nova work. Before the change the human readable name of 
> the security group could be used in {{templateOptions}}. Now the UUID of the 
> security group is required.
> Either document the change in the release notes or improve the code to 
> support the human readable name for backwards compatibility.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jclouds/jclouds] JCLOUDS-1323: use security group names in openstack nova template options (#1128)

2017-08-06 Thread Andrea Turli 
This patch is to validate the `templateOption.securityGroups` passed by the 
user. It accepts `securityGroupNames` as it uses to be before 
https://github.com/jclouds/jclouds/pull/1117 cc @neykov @nacx 

You can view, comment on, or merge this pull request online at:

  https://github.com/jclouds/jclouds/pull/1128

-- Commit Summary --

  * JCLOUDS-1323: use security group names in openstack nova template options

-- File Changes --

M 
apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/compute/strategy/ApplyNovaTemplateOptionsCreateNodesWithGroupEncodedIntoNameThenAddToSet.java
 (17)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/1128.patch
https://github.com/jclouds/jclouds/pull/1128.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1128

Re: [jclouds/jclouds-labs] JCLOUDS-1304: add azure customdata, JCLOUDS-1305: add support for ssh keys in keyvault (#398)

2017-08-06 Thread Svet 
@VRanga000 what do you think about splitting the PR into `customData` support 
and another one for keyvault support? The two don't seem to depend on each 
other, and we can merge `customData` without waiting for the rest.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds-labs/pull/398#issuecomment-320494861