[jira] [Commented] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath
[
https://issues.apache.org/jira/browse/JCLOUDS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840407#comment-17840407
]
ASF subversion and git services commented on JCLOUDS-1637:
--
Commit c73660dac8303266d875a4fabe63cc731ebdd437 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=c73660dac8 ]
JCLOUDS-1637: Use glassfish jaxb implementation
Required by jakarta.xml.bind-api.
> JClouds does not work with Jakarta XML bind on classpath
>
>
> Key: JCLOUDS-1637
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-core
>Affects Versions: 2.6.0
>Reporter: Philipp Nanz
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.6.1
>
>
> This is kind-of a follow up to JCLOUDS-1627:
> When you have Spring Boot 3.2 powered environment/classpath, JClouds will
> fail to start with {{{}java.lang.NoClassDefFoundError:
> javax/xml/bind/JAXBException{}}}.
> The issue basically stems from
> https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
> which is still pointing to {{javax.xml.bind}} classes.
> The most simplistic solution probably would be to just replace the package
> names with {{{}jakarta.xml.bind{}}}.
> However, if you want to continue supporting {{{}javax.xml.bind{}}}, a
> possible solution would be to have two different XMLParser implementations
> and then load either of them, depending on which JAXB variant is available on
> the classpath.
> For reference, I have created a simple demo application that showcases the
> problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]
> Thanks in advance for looking into it!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1637) JClouds does not work with Jakarta XML bind on classpath
[
https://issues.apache.org/jira/browse/JCLOUDS-1637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840401#comment-17840401
]
ASF subversion and git services commented on JCLOUDS-1637:
--
Commit 7a438ceebdc298a707d4ce8e1ec22bea2834bf3d in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=7a438ceebd ]
JCLOUDS-1637: Replace java.xml.bind uses
> JClouds does not work with Jakarta XML bind on classpath
>
>
> Key: JCLOUDS-1637
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1637
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core
>Affects Versions: 2.6.0
>Reporter: Philipp Nanz
>Assignee: Andrew Gaul
>Priority: Major
>
> This is kind-of a follow up to JCLOUDS-1627:
> When you have Spring Boot 3.2 powered environment/classpath, JClouds will
> fail to start with {{{}java.lang.NoClassDefFoundError:
> javax/xml/bind/JAXBException{}}}.
> The issue basically stems from
> https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/xml/internal/JAXBParser.java,
> which is still pointing to {{javax.xml.bind}} classes.
> The most simplistic solution probably would be to just replace the package
> names with {{{}jakarta.xml.bind{}}}.
> However, if you want to continue supporting {{{}javax.xml.bind{}}}, a
> possible solution would be to have two different XMLParser implementations
> and then load either of them, depending on which JAXB variant is available on
> the classpath.
> For reference, I have created a simple demo application that showcases the
> problem: [https://github.com/philippn/jclouds-vs-jakarta-xml-bind]
> Thanks in advance for looking into it!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1635) Add another blobstore Tier
[ https://issues.apache.org/jira/browse/JCLOUDS-1635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839205#comment-17839205 ] ASF subversion and git services commented on JCLOUDS-1635: -- Commit da1bc06f9efb626c03eb3119e9c77adf5b12f179 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=da1bc06f9e ] JCLOUDS-1635: Add COOL and COLD to Tier The former replaces INFREQUENT. References gaul/s3proxy#625. > Add another blobstore Tier > -- > > Key: JCLOUDS-1635 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1635 > Project: jclouds > Issue Type: New Feature > Components: jclouds-blobstore >Affects Versions: 2.6.0 >Reporter: Andrew Gaul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently jclouds supports STANDARD, INFREQUENT, and ARCHIVE. But AzureBlob, > GCS, and S3 all support at least 4 tiers. So let's add something cheaper > than INFREQUENT but faster than ARCHIVE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1634) Add AzureBlob cold access tier
[ https://issues.apache.org/jira/browse/JCLOUDS-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836911#comment-17836911 ] ASF subversion and git services commented on JCLOUDS-1634: -- Commit e1f34bbfa77619871fdf1af9b3090c8ff695869d in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=e1f34bbfa7 ] JCLOUDS-1634: Add AzureBlob COLD access tier References gaul/s3proxy#625. > Add AzureBlob cold access tier > -- > > Key: JCLOUDS-1634 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1634 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.6.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Minor > Labels: azureblob > > Currently jclouds only supports hot, cool, and archive: > https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1631) AWS S3, sign for authorization header failed if query part contains special chars
[ https://issues.apache.org/jira/browse/JCLOUDS-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836909#comment-17836909 ] ASF subversion and git services commented on JCLOUDS-1631: -- Commit 0688553087aabdaa7f503265bbc4a4cb60adef55 in jclouds's branch refs/heads/master from Maksim_Hadalau [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=0688553087 ] JCLOUDS-1631: fix AWSRequestAuthorizeSignatureV4 when prefix contains special chars > AWS S3, sign for authorization header failed if query part contains special > chars > - > > Key: JCLOUDS-1631 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1631 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.5.0 >Reporter: Maksim Hadalau >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Problem description: > Can not list blobs for aws-s3 provider if prefix contains special chars %/& > Steps to reproduce: > try to list blobs with following prefix: > "Folder (`~!@#$%^&*-_+[]'|<>.?) Name/" > Actual behavior: > Error: URLDecoder: Incomplete trailing escape (%) pattern > Expected behavior: > provided prefix must be listed > Problem location: > `AWSRequestAuthorizeSignatureV4.signForAuthorizationHeader()` > > Multimap queryMap = > queryParser().apply(request.getEndpoint().getQuery()); > request.getEndpoint().getQuery() - returns a decoded query string > however queryParser() require encoded one > Fix: > Multimap queryMap = > queryParser().apply(request.getEndpoint().getRawQuery()); > When jclouds generates a request to the AWS it encodes prefix (encoding all > special chars in it, including % and &), however calling `getQuery()` returns > decoded version of query string which lead to unpredictable behavior. > P.S. required patch in 2.5.x if possible > PR https://github.com/apache/jclouds/pull/200 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1630) UriTemplates.expand() silently cut storage prefix (blob key) if { (open curve bracket) ocured
[
https://issues.apache.org/jira/browse/JCLOUDS-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828964#comment-17828964
]
ASF subversion and git services commented on JCLOUDS-1630:
--
Commit bc43572d657956e013b094dfa08618c61a795e3d in jclouds's branch
refs/heads/master from Maxim
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=bc43572d65 ]
JCLOUDS-1630: Handle URI template properly with opened curve bracket (#199)
Co-authored-by: Maksim_Hadalau
> UriTemplates.expand() silently cut storage prefix (blob key) if { (open curve
> bracket) ocured
> -
>
> Key: JCLOUDS-1630
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1630
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore, jclouds-core
>Affects Versions: 2.5.0
>Reporter: Maksim Hadalau
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Steps to reproduce:
> Try to create a blob with opened curve in a storage key
>
> {code:java}
> // below test fails because actual result is: "/repos/folder with "
> public void testIncorrectExpand() {
> assertEquals(expand("/repos/folder with { brackets in a key",
> ImmutableMap.of()),
> "/repos/folder with { brackets in a key"); }
>
> {code}
> Solution, if no variables provided - return template as is.
> patch to 2.5.x if possible
> PR https://github.com/apache/jclouds/pull/199
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1632) GCP BlobStore fails to put a blob if blob name contains non ASCII characters
[
https://issues.apache.org/jira/browse/JCLOUDS-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17828950#comment-17828950
]
ASF subversion and git services commented on JCLOUDS-1632:
--
Commit b379c17156237de96cedbb19d82bc86168fe83af in jclouds's branch
refs/heads/master from Aliaksandr Stsiapanay
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=b379c17156 ]
JCLOUDS-1632: GCP BlobStore fails to put a blob if blob name contains non ASCII
characters
> GCP BlobStore fails to put a blob if blob name contains non ASCII characters
>
>
> Key: JCLOUDS-1632
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1632
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore, jclouds-core
>Affects Versions: 2.5.0
>Reporter: Aliaksandr
>Priority: Major
> Labels: GCP
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Steps to reproduce*:
> # Configure blob store using `google-cloud-storage`
> # Try to put a blob with name containing any Unicode character
> # The error occurred something like below
> {noformat}
> SEVERE: error after writing 389/409 bytes to
> https://www.googleapis.com/upload/storage/v1/b/gcp-dev/o?uploadType=multipart
> java.io.IOException: too many bytes written
> at
> java.base/sun.net.www.protocol.http.HttpURLConnection$StreamingOutputStream.write(HttpURLConnection.java:3812)
> at
> com.google.common.io.CountingOutputStream.write(CountingOutputStream.java:54)
> at org.jclouds.io.ByteStreams2.copy(ByteStreams2.java:73)
> at
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.writePayloadToConnection(JavaUrlHttpCommandExecutorService.java:302)
> at
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:175)
> at
> org.jclouds.http.internal.JavaUrlHttpCommandExecutorService.convert(JavaUrlHttpCommandExecutorService.java:66)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:97)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:91)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:74)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:45)
> at
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
> at
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
> at jdk.proxy3/jdk.proxy3.$Proxy86.multipartUpload(Unknown Source)
> at
> org.jclouds.googlecloudstorage.blobstore.GoogleCloudStorageBlobStore.putBlob(GoogleCloudStorageBlobStore.java:235)
> at
> org.jclouds.googlecloudstorage.blobstore.GoogleCloudStorageBlobStore.putBlob(GoogleCloudStorageBlobStore.java:207)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
> at jdk.proxy3/jdk.proxy3.$Proxy78.putBlob(Unknown Source)
> {noformat}
> *Root cause*
> The contractor
> org.jclouds.io.payloads.MultipartForm#MultipartForm(java.lang.String,
> java.lang.Iterable) doesn't calculate
> content's length properly.
> Specifically the constructor counts the length of
> org.jclouds.io.payloads.MultipartForm#createHeaders string instead of byte
> array length of that string to UTF-8
> AS a result a wrong content length is assigned to output stream causing the
> error above.
> *Solution*
> Use the length of a byte array instead of string length obtained from the
> method org.jclouds.io.payloads.MultipartForm#createHeaders
> See the PR https://github.com/apache/jclouds/pull/201
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1626) `FileInputStream` leak when using `filesystem` provider and performing a multipart upload
[
https://issues.apache.org/jira/browse/JCLOUDS-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822884#comment-17822884
]
ASF subversion and git services commented on JCLOUDS-1626:
--
Commit 4c7fb2c8b9f36207cd0b04f6266521412e6678f3 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=4c7fb2c8b9 ]
JCLOUDS-1626: Close stream in MultiBlobInputStream
Otherwise the inner FileInputStream will leak if the caller only reads
part of the stream before closing the outer MultiBlobInputStream.
> `FileInputStream` leak when using `filesystem` provider and performing a
> multipart upload
> -
>
> Key: JCLOUDS-1626
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1626
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Reporter: Ji Xinchi
>Priority: Critical
> Labels: filesystem
>
> I'm using gaul/s3proxy built on the latest jclouds. The provider
> configuration is "filesystem", and basedir configuration is a directory where
> a NFS is mounted.
>
> When I performed a multipart upload, I found that files such as
> ".nfs10bf0005" remained in the directory after uploading.
> Each file corresponded to one part and the files could not be deleted. The
> error "Device Busy" was reported. These files will disappear automatically
> after restarting s3proxy.
>
> I found this PR, and tried to restore following snippet and it worked. But
> this is just a temporary fix.
> {code:java}
> InputStream is = blob.getPayload().openStream();
> if (is instanceof FileInputStream) {
> // except for FileInputStream since large MPU can open too many
> fds
> is.close();
> payload = blob.getPayload();
> } else {
> blob.resetPayload(/*release=*/ false);
> payload = new InputStreamPayload(is);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1628) Netty 3.10.* has multiple security vulnerabilities
[ https://issues.apache.org/jira/browse/JCLOUDS-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820654#comment-17820654 ] ASF subversion and git services commented on JCLOUDS-1628: -- Commit 4f3955799bb8e419556c9590dd60faed5d3122dd in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=4f3955799b ] JCLOUDS-1628: Remove Netty driver 3.x has multiple security vulnerabilities but upgrading to 4.x is API incompatible. Remove due to lack of known users. > Netty 3.10.* has multiple security vulnerabilities > -- > > Key: JCLOUDS-1628 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1628 > Project: jclouds > Issue Type: Improvement > Components: jclouds-drivers >Affects Versions: 2.5.0 >Reporter: Andrew Gaul >Priority: Major > Labels: netty > Time Spent: 20m > Remaining Estimate: 0h > > Need to upgrade to 4.x to resolve this but this has multiple API changes. > Propose removing the driver entirely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1629) Upgrade to Guice 7
[ https://issues.apache.org/jira/browse/JCLOUDS-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820562#comment-17820562 ] ASF subversion and git services commented on JCLOUDS-1629: -- Commit 107741f786a6aabfd68617b4e2e4ff59efac675d in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=107741f786 ] JCLOUDS-1629: Upgrade to Guice 7.0.0 This also changes from javax to jakarta annotations. > Upgrade to Guice 7 > -- > > Key: JCLOUDS-1629 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1629 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 2.5.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: guice > Time Spent: 50m > Remaining Estimate: 0h > > [~basil] JCLOUDS-1627 upgrading some of the packages to jakarta but not the > important annotations one for Guice. When changing these to Jakarta I could > get Guice 7 working but not 6. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1627) Java Jakarta Support
[ https://issues.apache.org/jira/browse/JCLOUDS-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819981#comment-17819981 ] ASF subversion and git services commented on JCLOUDS-1627: -- Commit b5e4e1d0fd466dffcbb0fb7921e52732145cc732 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=b5e4e1d0fd ] JCLOUDS-1627: Upgrade to Jakarta packages This resolves an issue with newer Guice versions. > Java Jakarta Support > > > Key: JCLOUDS-1627 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1627 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 2.5.0 >Reporter: Paolo Bazzi >Assignee: Andrew Gaul >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Module jclouds-core (latest version 2.5.0) depends on non-jakarta version of > javax APIs: > - javax.annotation » javax.annotation-api > - javax.ws.rs » javax.ws.rs-api > > Are there any plans to release a version based on new Jakarta APIs instead of > former javax modules? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1606) Cannot upload more than 32 parts to GCS
[
https://issues.apache.org/jira/browse/JCLOUDS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819222#comment-17819222
]
ASF subversion and git services commented on JCLOUDS-1606:
--
Commit 47f34770c9daaa5fe0224ce5bc1adbb7332d9aea in jclouds's branch
refs/heads/master from Jan Vermeulen
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=47f34770c9 ]
JCLOUDS-1606: JCLOUDS-1608: Fix MPU off-by-one
Previously GCS could not upload large objects due to its 32 part
limit.
> Cannot upload more than 32 parts to GCS
> ---
>
> Key: JCLOUDS-1606
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1606
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.5.0
>Reporter: Lari Hotari
>Priority: Major
> Labels: google-cloud-storage
>
> There's currently a limitation in JClouds that it cannot upload more than 32
> parts to GCS.
> {code:java}
> org.jclouds.http.HttpResponseException: command: POST
> https://www.googleapis.com/storage/v1/b/somebucket/o/ff553922-1fa3-4ceb-abcd-60106603b5c8-object-123456/compose
> HTTP/1.1 failed with response: HTTP/1.1 400 Bad Request; content: [{
> "error": {
> "code": 400,
> "message": "The number of source components provided (35) exceeds the
> maximum (32)",
> "errors": [
> {
> "message": "The number of source components provided (35) exceeds the
> maximum (32)",
> "domain": "global",
> "reason": "invalid"
> }
> ]
> }
> } {code}
> The limitation of 32 parts is per API call to the compose endpoint.
>
> When there are more than 32 parts, the endpoint should be called multiple
> times. The total limit is 1 parts in GCS.
> [https://cloud.google.com/storage/docs/composite-objects]
>
> {quote}When you perform a composition:
> * The source objects are unaffected.
> * You can use between {*}1 and 32 source objects{*}.
> * {*}Source objects can themselves be composite objects{*}.{quote}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1608) Slicing of large files can lead to exceed the 32 parts limit of GCS
[
https://issues.apache.org/jira/browse/JCLOUDS-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819223#comment-17819223
]
ASF subversion and git services commented on JCLOUDS-1608:
--
Commit 47f34770c9daaa5fe0224ce5bc1adbb7332d9aea in jclouds's branch
refs/heads/master from Jan Vermeulen
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=47f34770c9 ]
JCLOUDS-1606: JCLOUDS-1608: Fix MPU off-by-one
Previously GCS could not upload large objects due to its 32 part
limit.
> Slicing of large files can lead to exceed the 32 parts limit of GCS
> ---
>
> Key: JCLOUDS-1608
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1608
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.1, 2.5.0
>Reporter: Jan Vermeulen
>Priority: Major
> Labels: google-cloud-storage
>
> MultipartUploadSlicingAlgorithm calculates slices for a large file by first
> using the defaultPartSize. If the results of that slicing gives parts that
> don't exceed the min/maxPartSizes (5MB and 5GB for
> GoogleCloudStorageBlobStore) but that do exceed the maxNumberOfParts (32 for
> GoogleCloudStorageBlobStore), the algoritm sets the number of parts to 32 and
> recalculates the size of the parts. If there is any remainder after that,
> JClouds ends up uploading 33 parts in total to GCS, causing the process to
> fail in completeMultipartUpload() when recomposing the original content from
> the parts.
> The following simple unitTest proves the case:
> {{public class AlgoritmTest extends TestCase {}}
> {{ public void testSlicing() {}}
> {{ MultipartUploadSlicingAlgorithm algorithm = new
> MultipartUploadSlicingAlgorithm(1024*1024*5,1024*1024*1024*5,32);}}
> {{ algorithm.calculateChunkSize(1024*1024*1200+33);}}
> {{ assertTrue(algorithm.getParts()+((algorithm.getRemaining() >
> 0)?(1):(0)) <= 32);}}
> {{}}}
> It simulates the slicing of a file of 1.2GB+33 bytes (to make sure there is a
> remainder).
> The following patch fixes the issue:
> {{ ...}}
> {{ long remainder = length % unitPartSize; }}
> {{ // SHB patch}}
> {{ // remainder should be distributed over parts if we are at the
> maximumNumberOfParts}}
> {{ // (if not, an additional part is uploaded to GCS thus exceeding the
> maximum allowed parts)}}
> {{ // if (remainder == 0 && parts > 0) {}}
> {{ // parts -= 1;}}
> {{ if (remainder > 0 && parts == maximumNumberOfParts) {}}
> {{ parts -= 1;}}
> {{ partSize = length/parts;}}
> {{// end of SHB patch}}
> {{ ...}}
> I also commented the code that reduces the number of parts when there is no
> remainder, since that ends up creating a remaining part that is the same size
> as the others.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1519) Support for Backblaze application keys
[ https://issues.apache.org/jira/browse/JCLOUDS-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818764#comment-17818764 ] ASF subversion and git services commented on JCLOUDS-1519: -- Commit 41d842d449e125411709613e27ca01c8fc5c4a4f in jclouds's branch refs/heads/dependabot/maven/project/org.testng-testng-7.5.1 from davidsenk [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=41d842d449 ] JCLOUDS-1519: Fix the authorization error with b2 application keys > Support for Backblaze application keys > -- > > Key: JCLOUDS-1519 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1519 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.1.2 >Reporter: Elton Carneiro >Assignee: Andrew Gaul >Priority: Major > Fix For: 2.6.0 > > > The current implementation of the B2 API in JClouds only supports Master Keys > and not application keys. > When using the Master Key, the Key ID and the Account ID are the same. > However, when using Application Keys, the Key ID of the application key is > not the same as the account ID. The account ID is what is needed to make > certain calls such as bucket operations. > The response of the > [b2_authorize_account|https://www.backblaze.com/b2/docs/b2_authorize_account.html] > contains the account ID. > If you look at the > [b2_list_buckets|https://www.backblaze.com/b2/docs/b2_list_buckets.html] > endpoint, it takes in an account ID. This Account ID is returned in the > authorize call. > Looking at the source code, It seems that the account ID is being pulled from > the credentials that the user entered versus the response from the authorize > call. > This issue prevents users from using Application keys when using JClouds. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1519) Support for Backblaze application keys
[ https://issues.apache.org/jira/browse/JCLOUDS-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818322#comment-17818322 ] ASF subversion and git services commented on JCLOUDS-1519: -- Commit 41d842d449e125411709613e27ca01c8fc5c4a4f in jclouds's branch refs/heads/master from davidsenk [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=41d842d449 ] JCLOUDS-1519: Fix the authorization error with b2 application keys > Support for Backblaze application keys > -- > > Key: JCLOUDS-1519 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1519 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.1.2 >Reporter: Elton Carneiro >Priority: Major > > The current implementation of the B2 API in JClouds only supports Master Keys > and not application keys. > When using the Master Key, the Key ID and the Account ID are the same. > However, when using Application Keys, the Key ID of the application key is > not the same as the account ID. The account ID is what is needed to make > certain calls such as bucket operations. > The response of the > [b2_authorize_account|https://www.backblaze.com/b2/docs/b2_authorize_account.html] > contains the account ID. > If you look at the > [b2_list_buckets|https://www.backblaze.com/b2/docs/b2_list_buckets.html] > endpoint, it takes in an account ID. This Account ID is returned in the > authorize call. > Looking at the source code, It seems that the account ID is being pulled from > the credentials that the user entered versus the response from the authorize > call. > This issue prevents users from using Application keys when using JClouds. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1618) Jclouds 2.3.0 and above is incompatible with SpringBoot 2.7.*
[
https://issues.apache.org/jira/browse/JCLOUDS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17818285#comment-17818285
]
ASF subversion and git services commented on JCLOUDS-1618:
--
Commit 8075bbe50aced7c75ee089fe76ba64e6b8e6afd2 in jclouds's branch
refs/heads/dependabot/maven/project/org.testng-testng-7.5.1 from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=8075bbe50a ]
JCLOUDS-1618: Upgrade to gson 2.10.1
> Jclouds 2.3.0 and above is incompatible with SpringBoot 2.7.*
> -
>
> Key: JCLOUDS-1618
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1618
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core
>Affects Versions: 2.3.0, 2.4.0, 2.5.0
>Reporter: Biswa Ranjan Ray
>Assignee: Andrew Gaul
>Priority: Major
> Labels: gson
> Fix For: 2.6.0
>
> Attachments: JClouds_Gson_Error.txt
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Hi,
> We developed a multi-cloud application using jclouds and springboot to
> support operations on storage services e.g s3, gcs and azure storage.
> We're trying to migrate our application from springboot 2.5.* to latest
> (springboot 2.7.*). However we're facing issues with jclouds. Its observed
> that errors are thrown during the creation of BlobStoreContext. A full
> stacktrace is attached.
> Here is a code snippet of BlobStoreContext:
> public BlobStoreContext getBlobStoreContext()
> {
>return ContextBuilder.newBuilder(CloudProviders.PROVIDER_AWS.toString())
>
>.credentials(this.getAccessKeyId(), this.getSecretAccessKey())
>.buildView(BlobStoreContext.class);
> }
> We also tried jclouds 2.4.0 & 2.5.0 but no luck. However its found jclouds
> 2.3.0 is compatible with springboot 2.6.10 and currently we're using the
> same, but our goal is to upgrade to springboot 2.7.
> Any suggestions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1618) Jclouds 2.3.0 and above is incompatible with SpringBoot 2.7.*
[
https://issues.apache.org/jira/browse/JCLOUDS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733279#comment-17733279
]
ASF subversion and git services commented on JCLOUDS-1618:
--
Commit 8075bbe50aced7c75ee089fe76ba64e6b8e6afd2 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=8075bbe50a ]
JCLOUDS-1618: Upgrade to gson 2.10.1
> Jclouds 2.3.0 and above is incompatible with SpringBoot 2.7.*
> -
>
> Key: JCLOUDS-1618
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1618
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core
>Affects Versions: 2.3.0, 2.4.0, 2.5.0
>Reporter: Biswa Ranjan Ray
>Assignee: Andrew Gaul
>Priority: Major
> Labels: gson
> Attachments: JClouds_Gson_Error.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Hi,
> We developed a multi-cloud application using jclouds and springboot to
> support operations on storage services e.g s3, gcs and azure storage.
> We're trying to migrate our application from springboot 2.5.* to latest
> (springboot 2.7.*). However we're facing issues with jclouds. Its observed
> that errors are thrown during the creation of BlobStoreContext. A full
> stacktrace is attached.
> Here is a code snippet of BlobStoreContext:
> public BlobStoreContext getBlobStoreContext()
> {
>return ContextBuilder.newBuilder(CloudProviders.PROVIDER_AWS.toString())
>
>.credentials(this.getAccessKeyId(), this.getSecretAccessKey())
>.buildView(BlobStoreContext.class);
> }
> We also tried jclouds 2.4.0 & 2.5.0 but no luck. However its found jclouds
> 2.3.0 is compatible with springboot 2.6.10 and currently we're using the
> same, but our goal is to upgrade to springboot 2.7.
> Any suggestions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1371) LocalBlobStore.list enumerates entire container
[
https://issues.apache.org/jira/browse/JCLOUDS-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17680099#comment-17680099
]
ASF subversion and git services commented on JCLOUDS-1371:
--
Commit 62632c9db658808c14a729aa58b4364c4323e35c in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=62632c9db6 ]
JCLOUDS-1371: Optimize filesystem delimiter
populateBlobKeysInContainer will no longer recurse when the delimiter
matches "/". This makes listing deep hierarchies with a delimiter
faster. Note that the general LocalBlobStore handling is still
required for the general cases. This requires removing a bogus test
case. References gaul/s3proxy#473.
> LocalBlobStore.list enumerates entire container
> ---
>
> Key: JCLOUDS-1371
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1371
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 2.0.3
>Reporter: Andrew Gaul
>Priority: Major
> Labels: filesystem
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{LocalBlobStore.list}} with the filesystem blobstore enumerates the entire
> container even when prefix and delimiter set. The File API does not provide
> a way to list a subset of files except for those within a specific directory
> and the underlying filesystem makes no guarantees about enumeration order.
> We can still optimize the case where prefix is set and delimiter is /.
> Reference:
> https://lists.apache.org/thread.html/72e8a101d8a8f99b6f728336633db2cecae1dc443e4c5b195eee8f0d@%3Cuser.jclouds.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1488) Filesystem list call with prefix is slow in large containers
[
https://issues.apache.org/jira/browse/JCLOUDS-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679526#comment-17679526
]
ASF subversion and git services commented on JCLOUDS-1488:
--
Commit e478dd5452d70a5ea2082337b05ad91f331f0eb6 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=e478dd5452 ]
JCLOUDS-1371: JCLOUDS-1488: optimize fs prefix
This reduces the number of stat calls required when prefix is deep in the
filesystem hierarchy. Further optimizations to delimiter are possible.
References gaul/s3proxy#473.
> Filesystem list call with prefix is slow in large containers
>
>
> Key: JCLOUDS-1488
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1488
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.1.1
> Environment: Java version: java version "1.8.0_131"
> Operating system: Fedora 27 x86_64
>Reporter: Lari Sinisalo
>Assignee: Andrew Gaul
>Priority: Major
> Labels: filesystem
> Fix For: 2.2.0, 2.1.2
>
> Attachments: JCLOUDS1488.java
>
>
> When the filesystem blobstore is used, running the following code takes very
> long if there are a lot of files in the container:
> {code:java}
> ListContainerOptions options = new ListContainerOptions();
> options.prefix("test-container-subdirectory/");
> Set results =
> blobStore.list("test-container",options);
> {code}
> See the attached Java source file [^JCLOUDS1488.java] for the full code.
> On my system, running the attached Java code takes over 10 seconds to list a
> single file if there are 500,000 files in the container outside that prefix.
> Output from the attached code:
> {code:java}
> Number of blobs listed: 1
> First listed blob: test-container-subdirectory/file-to-list
> Time it took to list the blobs: 13256 ms
> {code}
> A more general version of this problem was reported previously in
> JCLOUDS-1371.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1371) LocalBlobStore.list enumerates entire container
[
https://issues.apache.org/jira/browse/JCLOUDS-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17679525#comment-17679525
]
ASF subversion and git services commented on JCLOUDS-1371:
--
Commit e478dd5452d70a5ea2082337b05ad91f331f0eb6 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=e478dd5452 ]
JCLOUDS-1371: JCLOUDS-1488: optimize fs prefix
This reduces the number of stat calls required when prefix is deep in the
filesystem hierarchy. Further optimizations to delimiter are possible.
References gaul/s3proxy#473.
> LocalBlobStore.list enumerates entire container
> ---
>
> Key: JCLOUDS-1371
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1371
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-blobstore
>Affects Versions: 2.0.3
>Reporter: Andrew Gaul
>Priority: Major
> Labels: filesystem
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {{LocalBlobStore.list}} with the filesystem blobstore enumerates the entire
> container even when prefix and delimiter set. The File API does not provide
> a way to list a subset of files except for those within a specific directory
> and the underlying filesystem makes no guarantees about enumeration order.
> We can still optimize the case where prefix is set and delimiter is /.
> Reference:
> https://lists.apache.org/thread.html/72e8a101d8a8f99b6f728336633db2cecae1dc443e4c5b195eee8f0d@%3Cuser.jclouds.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1617) Fix HTTPS support in OkHttpCommandExecutorService
[ https://issues.apache.org/jira/browse/JCLOUDS-1617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17605426#comment-17605426 ] ASF subversion and git services commented on JCLOUDS-1617: -- Commit d913a5603727d10d6b85afa68c5ed6f6027f3e94 in jclouds's branch refs/heads/master from SATYANAN-ANAND [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=d913a56037 ] JCLOUDS-1617: Fix HTTPS support in OkHttpCommandExecutorService (#153) * JCLOUDS-1617: Fix HTTPS support in OkHttpCommandExecutorService Added support for proxy server type = HTTPS * Update DelegatingSocketFactory.java Added java doc > Fix HTTPS support in OkHttpCommandExecutorService > - > > Key: JCLOUDS-1617 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1617 > Project: jclouds > Issue Type: Bug >Reporter: Anand >Assignee: Andrew Gaul >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Hi, > In our project, we need to support Proxy Server with HTTPS type. > When the API request is called, OkHttpCommandExecutorService.invoke method > doesn't support ssl during okHttpClient builder. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1616) Proxy credentials validation is missing in OkHttpCommandExecutorService API request
[
https://issues.apache.org/jira/browse/JCLOUDS-1616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574700#comment-17574700
]
ASF subversion and git services commented on JCLOUDS-1616:
--
Commit 88f0c341cfc4a6508db63794846e7c3902b8e255 in jclouds's branch
refs/heads/master from SATYANAN-ANAND
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=88f0c341cf ]
JCLOUDS-1616: Proxy credentials validation is missing in
OkHttpCommandExecutorService API request
Added support for credentials validation
> Proxy credentials validation is missing in OkHttpCommandExecutorService API
> request
> ---
>
> Key: JCLOUDS-1616
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1616
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core, jclouds-drivers
>Reporter: Anand
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Hi,
> In our project, Azure ComputeServiceContext is constructed with proxy setting
> properties (includes credentials) as below,
> overrides.setProperty(Constants.*PROPERTY_PROXY_HOST*, "...");
> overrides.setProperty(Constants.*PROPERTY_PROXY_PORT*, "..");
> overrides.setProperty(Constants.*PROPERTY_PROXY_TYPE*,
> Proxy.Type.HTTP.name());
> overrides.setProperty(Constants.*PROPERTY_PROXY_USER*, "...");
> overrides.setProperty(Constants.*PROPERTY_PROXY_PASSWORD*, "...");
> ComputeServiceContext context =
> ContextBuilder.newBuilder("azurecompute-arm").credentials(identity,
> credential)
>
> .overrides(overrides).buildView(ComputeServiceContext.class);
> When the API request is called, OkHttpCommandExecutorService.invoke method
> doesn't populate the credentials in the proxyAuthenticator during
> okHttpClient builder.
> Therefore validation of credentials is ignored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (JCLOUDS-1609) upgrade bouncycastle due to cve
[ https://issues.apache.org/jira/browse/JCLOUDS-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17555871#comment-17555871 ] ASF subversion and git services commented on JCLOUDS-1609: -- Commit aea26037334665c544624d63916d8b2346d2da4e in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=aea2603733 ] JCLOUDS-1609: Upgrade to BouncyCastle 1.71 Release notes: https://www.bouncycastle.org/releasenotes.html#r1rv71 > upgrade bouncycastle due to cve > --- > > Key: JCLOUDS-1609 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1609 > Project: jclouds > Issue Type: Improvement >Reporter: PJ Fanning >Assignee: Andrew Gaul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > https://github.com/advisories/GHSA-6xx3-rg99-gc3p > https://github.com/pjfanning/jclouds/pull/1 was generated by dependabot in my > fork (which is up to date) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JCLOUDS-1602) upgrade jetty to 9.4.45 due to cve
[ https://issues.apache.org/jira/browse/JCLOUDS-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553246#comment-17553246 ] ASF subversion and git services commented on JCLOUDS-1602: -- Commit d4043916518f73fab75756e46e41b53ecd37c644 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=d404391651 ] JCLOUDS-1602: Upgrade to Jetty 9.4.46 Remove BaseJettyTest which BaseMockWebServerTest superseded. > upgrade jetty to 9.4.45 due to cve > -- > > Key: JCLOUDS-1602 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1602 > Project: jclouds > Issue Type: Bug >Reporter: PJ Fanning >Assignee: Andrew Gaul >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > https://github.com/apache/jclouds/blob/master/project/pom.xml#L233 > https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server has links > to the cves on various releases -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JCLOUDS-1603) upgrade guava due to security issue
[ https://issues.apache.org/jira/browse/JCLOUDS-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553245#comment-17553245 ] ASF subversion and git services commented on JCLOUDS-1603: -- Commit 7eb64f48504e72a02cffce031bdf2622aa024f45 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=7eb64f4850 ] JCLOUDS-1603: Upgrade to Guava 31.1 > upgrade guava due to security issue > --- > > Key: JCLOUDS-1603 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1603 > Project: jclouds > Issue Type: Bug >Reporter: PJ Fanning >Assignee: Andrew Gaul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > https://mvnrepository.com/artifact/com.google.guava/guava > https://github.com/apache/jclouds/blob/master/project/pom.xml#L225 this guava > version has an open cve -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (JCLOUDS-1604) use non-beta/rc versions of auto-factory
[ https://issues.apache.org/jira/browse/JCLOUDS-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523687#comment-17523687 ] ASF subversion and git services commented on JCLOUDS-1604: -- Commit 27274d40a946b8d52e06757e3a18076cb73ab3b5 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=27274d40a9 ] JCLOUDS-1604: Upgrade to AutoFactory 1.0.1 > use non-beta/rc versions of auto-factory > > > Key: JCLOUDS-1604 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1604 > Project: jclouds > Issue Type: Improvement >Reporter: PJ Fanning >Assignee: Andrew Gaul >Priority: Major > > auto-factory and auto-service appear to have official releases now > see https://github.com/apache/jclouds/blob/master/project/pom.xml#L229 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1601) upgrade log4j due to security issue
[ https://issues.apache.org/jira/browse/JCLOUDS-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523688#comment-17523688 ] ASF subversion and git services commented on JCLOUDS-1601: -- Commit 659951bc63368bb1eed8d2e25b2ae5ed79476e56 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=659951bc63 ] JCLOUDS-1601: Upgrade to log4j 2.17.2 Release notes: https://logging.apache.org/log4j/2.x/changes-report.html#a2.17.2 > upgrade log4j due to security issue > --- > > Key: JCLOUDS-1601 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1601 > Project: jclouds > Issue Type: Bug >Reporter: PJ Fanning >Assignee: Andrew Gaul >Priority: Major > > There is a CVE against v2.17.0 > https://github.com/apache/jclouds/blob/master/project/pom.xml#L239 > https://logging.apache.org/log4j/2.x/security.html > Also, logback version is old (next line in pom) > https://mvnrepository.com/artifact/ch.qos.logback/logback-core -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1599) Add support for GLACIER_IR storage class
[ https://issues.apache.org/jira/browse/JCLOUDS-1599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503232#comment-17503232 ] ASF subversion and git services commented on JCLOUDS-1599: -- Commit 5fad7fa895c02c1a8394175032a47a8bb175e84d in jclouds's branch refs/heads/master from ramahin [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=5fad7fa ] JCLOUDS-1599 - Add support for GLACIER_IR storage class > Add support for GLACIER_IR storage class > > > Key: JCLOUDS-1599 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1599 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 2.4.0, 2.5.0 >Reporter: Ryan Mahin >Assignee: Andrew Gaul >Priority: Trivial > Fix For: 2.5.0 > > Original Estimate: 0.5h > Time Spent: 10m > Remaining Estimate: 20m > > An exception is raised when listing objects using Amazon's new Glacier > Instant Retrieval storage class. I think we just need to add a new enum value -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1598) Support Metric Alert Operations
[ https://issues.apache.org/jira/browse/JCLOUDS-1598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498244#comment-17498244 ] ASF subversion and git services commented on JCLOUDS-1598: -- Commit 83deb0efef180f75c05d291e4a03d45d59bd0bce in jclouds's branch refs/heads/master from SATYANAN-ANAND [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=83deb0e ] JCLOUDS-1598: Support Metric Alert Operation (#134) > Support Metric Alert Operations > --- > > Key: JCLOUDS-1598 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1598 > Project: jclouds > Issue Type: New Feature > Components: jclouds-compute >Reporter: Anand >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Support Metric Alert Operations > https://docs.microsoft.com/en-us/rest/api/monitor/metric-alerts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1597) Support Alerts operations
[ https://issues.apache.org/jira/browse/JCLOUDS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495452#comment-17495452 ] ASF subversion and git services commented on JCLOUDS-1597: -- Commit 99f2ff86dae81c51834271b80a56fdac47719dfd in jclouds's branch refs/heads/master from SATYANAN-ANAND [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=99f2ff8 ] JCLOUDS-1597: Support for Alerts (#133) > Support Alerts operations > - > > Key: JCLOUDS-1597 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1597 > Project: jclouds > Issue Type: New Feature >Reporter: Anand >Priority: Major > Fix For: 2.5.0 > > Time Spent: 6h > Remaining Estimate: 0h > > https://docs.microsoft.com/en-us/rest/api/monitor/alertsmanagement/alerts > Support required for Alerts Operations -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1596) Support Activity Log Alert Operations
[ https://issues.apache.org/jira/browse/JCLOUDS-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487427#comment-17487427 ] ASF subversion and git services commented on JCLOUDS-1596: -- Commit 2b16b55e09259b57f74792fd0d5cc9d0b912 in jclouds's branch refs/heads/master from SATYANAN-ANAND [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=2b16b55 ] JCLOUDS-1596: Support Activity Log Alert Operations > Support Activity Log Alert Operations > - > > Key: JCLOUDS-1596 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1596 > Project: jclouds > Issue Type: New Feature >Reporter: Anand >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > https://docs.microsoft.com/en-us/rest/api/monitor/activity-log-alerts > Support required for Activity Log Alerts Operations -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1594) Allow overriding S3 with V4 signing
[ https://issues.apache.org/jira/browse/JCLOUDS-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17474519#comment-17474519 ] ASF subversion and git services commented on JCLOUDS-1594: -- Commit 468b126dd856b48ff89f423b649ec4e3b19af012 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=468b126 ] JCLOUDS-1594: Allow overriding S3 signer Previously s3 always used v2 and aws-s3 always used v4. Now s3 defaults to v2 and can override to v4. Note that this does not change BlobRequestSigner. > Allow overriding S3 with V4 signing > --- > > Key: JCLOUDS-1594 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1594 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: s3 > Time Spent: 20m > Remaining Estimate: 0h > > Currently the S3 provider can only use the V2 signer while AWS can only use > the V4 signer. Allowing configuration of the former will improve > compatibility with some non-AWS services that don't allow V2. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1591) OAuth: ClientCredentialsJWTBearerTokenFlow.filter method throws Null Pointer Exception
[ https://issues.apache.org/jira/browse/JCLOUDS-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17465564#comment-17465564 ] ASF subversion and git services commented on JCLOUDS-1591: -- Commit c95ddff0205ce2c54fe2f677769e71a59417835d in jclouds's branch refs/heads/master from SATYANAN-ANAND [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=c95ddff ] JCLOUDS-1591: Fix NPE in ClientCredentialsClaims > OAuth: ClientCredentialsJWTBearerTokenFlow.filter method throws Null Pointer > Exception > -- > > Key: JCLOUDS-1591 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1591 > Project: jclouds > Issue Type: Bug >Affects Versions: 2.4.0 >Reporter: Anand >Priority: Major > Labels: oauth > Attachments: log.txt > > > Null pointer exception is thrown when > ClientCredentialsJWTBearerTokenFlow.filter() creates ClientCredentialsClaims > using "null" in jti placeholder > Class: org.jclouds.oauth.v2.filters.ClientCredentialsJWTBearerTokenFlow > Method: filter > Lines#: > ClientCredentialsClaims claims = ClientCredentialsClaims.create( // > credentialsSupplier.get().identity, // iss > credentialsSupplier.get().identity, // sub > oauthConfig.audience(), // aud > -1, // placeholder exp for the cache > -1, // placeholder nbf for the cache > null // placeholder jti for the cache > ); > Ran into this exception during OAuth using > org.jclouds.oauth.v2.config.CredentialType.CLIENT_CREDENTIALS_P12_AND_CERTIFICATE. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1589) Upgrade to Log4j 2.16.0
[ https://issues.apache.org/jira/browse/JCLOUDS-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462043#comment-17462043 ] ASF subversion and git services commented on JCLOUDS-1589: -- Commit 1a4bcd5547a89c7f097b9dcc4cff7e4a137bc668 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=1a4bcd5 ] JCLOUDS-1589: Upgrade to log4j 2.17.0 This addresses a high severity CVE: https://logging.apache.org/log4j/2.x/security.html > Upgrade to Log4j 2.16.0 > --- > > Key: JCLOUDS-1589 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1589 > Project: jclouds > Issue Type: Improvement > Components: jclouds-drivers >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: log4j > Fix For: 2.5.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 2.15.0 fixes a critical CVE: > [https://logging.apache.org/log4j/2.x/security.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1590) Promote glacier to core
[ https://issues.apache.org/jira/browse/JCLOUDS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461749#comment-17461749 ] ASF subversion and git services commented on JCLOUDS-1590: -- Commit a91eb7affaae71aa4a6fd71f3df45d0e9f6b520e in jclouds-labs-aws's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds-labs-aws.git;h=a91eb7a ] JCLOUDS-1590: Promote glacier to core > Promote glacier to core > --- > > Key: JCLOUDS-1590 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1590 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: glacier > Time Spent: 0.5h > Remaining Estimate: 0h > > Maybe we can promote or jettison the other providers in jclouds-labs-aws as > well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1590) Promote glacier to core
[ https://issues.apache.org/jira/browse/JCLOUDS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461742#comment-17461742 ] ASF subversion and git services commented on JCLOUDS-1590: -- Commit 3bbb0b446ac6945d18908e2009b203685738df75 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=3bbb0b4 ] JCLOUDS-1590: Promote glacier to core > Promote glacier to core > --- > > Key: JCLOUDS-1590 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1590 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: glacier > Time Spent: 20m > Remaining Estimate: 0h > > Maybe we can promote or jettison the other providers in jclouds-labs-aws as > well. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1333) Cannot compile jclouds with Guava 21+
[
https://issues.apache.org/jira/browse/JCLOUDS-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461740#comment-17461740
]
ASF subversion and git services commented on JCLOUDS-1333:
--
Commit 3e25b835c6b9b3495a6435b16a3cfa9a1bc87249 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=3e25b83 ]
JCLOUDS-1333: Fix Guava 21 issues
> Cannot compile jclouds with Guava 21+
> -
>
> Key: JCLOUDS-1333
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1333
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-core
>Affects Versions: 2.1.0
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
> Labels: guava
> Fix For: 2.3.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> jclouds has compatibility with Guava 18-22 but we cannot compile using 21+
> due to some kind of Guava vs Java 8 Function class type error:
> {noformat}
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:102:
> error: method compose in interface java.util.function.Function cannot
> be applied to given types;
> transformer = compose(Function.class.cast(wrappingTransformer),
> transformer);
>^
> required: java.util.function.Function
> found:
> com.google.common.base.Function,com.google.common.base.Function
> reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
> where V,T,R are type-variables:
> V extends Object declared in method
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
> where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:189:
> error: method compose in interface java.util.function.Function cannot
> be applied to given types;
> transformer = compose(new OnlyElementOrNull(), transformer);
> ^
> required: java.util.function.Function
> found:
> OnlyElementOrNull,com.google.common.base.Function
> reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
> where V,T,R are type-variables:
> V extends Object declared in method
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
> where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> {noformat}
> This does not affect applications from using Guava 21-22 but does impact our
> compatibility testing. Note that you need to set {{maven.compile.source}} to
> 1.8 to test Guava 21+.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1589) Upgrade to Log4j 2.16.0
[ https://issues.apache.org/jira/browse/JCLOUDS-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461741#comment-17461741 ] ASF subversion and git services commented on JCLOUDS-1589: -- Commit 66ef18c6ae9983f13a9c1402520598eb8a2fdf6e in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=66ef18c ] JCLOUDS-1589: Upgrade to log4j 2.16.0 This addresses a critical CVE: https://logging.apache.org/log4j/2.x/security.html > Upgrade to Log4j 2.16.0 > --- > > Key: JCLOUDS-1589 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1589 > Project: jclouds > Issue Type: Improvement > Components: jclouds-drivers >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: log4j > Fix For: 2.5.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 2.15.0 fixes a critical CVE: > [https://logging.apache.org/log4j/2.x/security.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1589) Upgrade to Log4j 2.16.0
[ https://issues.apache.org/jira/browse/JCLOUDS-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461187#comment-17461187 ] ASF subversion and git services commented on JCLOUDS-1589: -- Commit f85534b8bf2110a07fc279b8996aec4507001511 in jclouds-labs-aws's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds-labs-aws.git;h=f85534b ] JCLOUDS-1589: Upgrade to log4j 2.16.0 This addresses a critical CVE: https://logging.apache.org/log4j/2.x/security.html > Upgrade to Log4j 2.16.0 > --- > > Key: JCLOUDS-1589 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1589 > Project: jclouds > Issue Type: Improvement > Components: jclouds-drivers >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: log4j > Fix For: 2.5.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 2.15.0 fixes a critical CVE: > [https://logging.apache.org/log4j/2.x/security.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1589) Upgrade to Log4j 2.15.0
[ https://issues.apache.org/jira/browse/JCLOUDS-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460790#comment-17460790 ] ASF subversion and git services commented on JCLOUDS-1589: -- Commit dbd8eb1dabc2c0f0349388fdffcca6cb8819f07c in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=dbd8eb1 ] JCLOUDS-1589: Upgrade to log4j 2.16.0 This addresses a critical CVE: https://logging.apache.org/log4j/2.x/security.html > Upgrade to Log4j 2.15.0 > --- > > Key: JCLOUDS-1589 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1589 > Project: jclouds > Issue Type: Improvement > Components: jclouds-drivers >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Priority: Major > Labels: log4j > Time Spent: 20m > Remaining Estimate: 0h > > 2.15.0 fixes a critical CVE: > [https://logging.apache.org/log4j/2.x/security.html] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1588) Vulnerability detected in gson <2.8.9
[ https://issues.apache.org/jira/browse/JCLOUDS-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441662#comment-17441662 ] ASF subversion and git services commented on JCLOUDS-1588: -- Commit 14e92fc8c82bc47ef90a25ee219861069ecf3193 in jclouds's branch refs/heads/master from Juan Cabrerizo [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=14e92fc ] JCLOUDS-1588: Bump google gson to 2.8.9 due to detected vulnerability (#124) > Vulnerability detected in gson <2.8.9 > - > > Key: JCLOUDS-1588 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1588 > Project: jclouds > Issue Type: Bug >Reporter: Juan D. Cabrerizo >Priority: Major > > Snyk identifies now the previos versions of Google gson as vulnerable. The PR > updates gson to the fixed version. > Snyk report: > [https://security.snyk.io/vuln/SNYK-JAVA-COMGOOGLECODEGSON-1730327] > gson PR: [google/gson#1991|https://github.com/google/gson/pull/1991] > > https://github.com/apache/jclouds/pull/124 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1586) Upgrade to Guice 5.0.1
[ https://issues.apache.org/jira/browse/JCLOUDS-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441438#comment-17441438 ] ASF subversion and git services commented on JCLOUDS-1586: -- Commit 7fffa5915827bdbf541b51f86a1d173666e951b0 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=7fffa59 ] JCLOUDS-1586: Upgrade to Guice 5.0.1 Guice 4.2.3 makes illegal reflective accesses that Java 17 does not allow. References google/guice#1133. Release notes: https://github.com/google/guice/wiki/Guice501 > Upgrade to Guice 5.0.1 > -- > > Key: JCLOUDS-1586 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1586 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 2.4.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Guice 4.2.3 makes illegal reflective accesses that Java 17 does not allow: > > [https://github.com/google/guice/wiki/Guice501#changes-since-guice-423] > [https://github.com/google/guice/issues/1133] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (JCLOUDS-1584) Deployment API fails when ARM Template deploys for creating Azure VM
[ https://issues.apache.org/jira/browse/JCLOUDS-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17409891#comment-17409891 ] ASF subversion and git services commented on JCLOUDS-1584: -- Commit 8167513c35bcb1c4ffaf34c9529bfcba14bb07ba in jclouds's branch refs/heads/master from Rajani-cloud [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=8167513 ] JCLOUDS-1584 : Deployment API fails when ARM Template deploys for creating Azure VM > Deployment API fails when ARM Template deploys for creating Azure VM > > > Key: JCLOUDS-1584 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1584 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute >Affects Versions: 2.3.0 >Reporter: Rajani Palavala >Priority: Major > Labels: azurecompute-arm > Attachments: Deployment.java, Value.java > > Time Spent: 20m > Remaining Estimate: 0h > > Hello, > we are using jclouds for azure compute operations. while using deployment API > for creating virtual machine using ARM Template get success but fails to get > the deployment details. > > while investigating we found two issues > *1.* java.lang.NullPointerException: Null > valuejava.lang.NullPointerException: Null value at > org.jclouds.azurecompute.arm.domain.AutoValue_Value.(AutoValue_Value.java:20) > at org.jclouds.azurecompute.arm.domain.Value.create(Value.java:39) > The ARM template have secure information (password) which Azure is not > returning the value when we do GET on the deployment, which is causing null > pointer @Value.java > *Solution:* We added @Nullable to value() which solved our issue. > > *2.* com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: > Expected a string but was BEGIN_ARRAY at line 1 column 472 path > $.properties.parameters..value > at > org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:193) > > The ARM Template have parameters which is type Array is the reason. > > *Solution:* We have modified parameter map value to JSONBALL to accept all > types of values. > > we would like to have patch including the solutions, please review and accept > the request. > Thanks. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1558) Azureblob Azure AD OAuth2 authentication support
[ https://issues.apache.org/jira/browse/JCLOUDS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17402738#comment-17402738 ] ASF subversion and git services commented on JCLOUDS-1558: -- Commit 0b68e8adee5e370184311c3fe4931ed8416d12d4 in jclouds's branch refs/heads/master from Timur Alperovich [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=0b68e8a ] JCLOUDS-1558: Implement Azure Blob Azure AD auth Implements the Azure AD authentication for Azure Blob, using the OAuth module. Added more parameters to the AzureBlob provider: - azureblob.auth - azureblob.account - azureblob.tenantId The "auth" parameter is used to specify whether Key/SAS auth or Active Directory is used. When using Active Directory auth, the identity no longer maps to the storage account, which has to be specified explicitly. The tenant ID also needs to be supplied to construct the auth URL to obtain the token correctly. > Azureblob Azure AD OAuth2 authentication support > > > Key: JCLOUDS-1558 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1558 > Project: jclouds > Issue Type: New Feature > Components: jclouds-blobstore >Affects Versions: 2.2.1 >Reporter: roded >Priority: Major > Labels: azureblob > Time Spent: 20m > Remaining Estimate: 0h > > We'd like to be able to access Azureblob via OAuth2 supplied by Azure AD. > This might be similar to the OAuth2 implementation in azurecompute-arm. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1582) ETag of the object uploaded via multipart upload does not match the CompleteMPU response from the transient blobstore
[ https://issues.apache.org/jira/browse/JCLOUDS-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17393761#comment-17393761 ] ASF subversion and git services commented on JCLOUDS-1582: -- Commit a1df0bb1f5f094774c81595fe8145d6f094a9ed6 in jclouds's branch refs/heads/master from Timur Alperovich [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=a1df0bb ] Store the MPU ETag for the transient blobstore JCLOUDS-1582: fixes a bug in the transient blobstore where after uploading a multipart upload, GET/HEAD returns the hash of the content, rather than the MPU ETag. > ETag of the object uploaded via multipart upload does not match the > CompleteMPU response from the transient blobstore > - > > Key: JCLOUDS-1582 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1582 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.3.0 >Reporter: Timur Alperovich >Priority: Minor > Labels: transient > > The local transient blobstore returns a correctly computed S3 MPU ETag when > completing the upload, but a subsequent GET/HEAD request returns the MD5 of > the whole object instead (not matching the ETag in the CompleteMPU response). > Ideally, jclouds should store the MPU ETag and return it on GET/HEAD requests. > This behavior also manifests when using the filesystem blobstore if the > extended attributes are not supported. In that case, there is nothing jclouds > can do. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-836) Support for the GAE
[
https://issues.apache.org/jira/browse/JCLOUDS-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17384100#comment-17384100
]
ASF subversion and git services commented on JCLOUDS-836:
-
Commit 1321043c0261e9a06cbd18ace064ba178b3b8f96 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=1321043 ]
Remove Google appengine driver
This has an incompatibility with JAXB motivating this removal.
jclouds GAE has not seen any development or issues in recent years and
uses a very old appengine-api-1.0-sdk dependency. Further it appears
to have modern Guava incompatibilities as seen in JCLOUDS-836.
> Support for the GAE
> ---
>
> Key: JCLOUDS-836
> URL: https://issues.apache.org/jira/browse/JCLOUDS-836
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore, jclouds-core, jclouds-drivers
>Affects Versions: 1.8.1
> Environment: When running jclouds on the Google App Engine (v1.9.18),
> the BlobStore API cannot work.
>Reporter: Edouard Mercier
>Priority: Major
> Labels: gae, google-cloud-storage
>
> Hello.
> I've been digging a long time, both using the v1.8.1 and the v2.0.0-SNAPSHOT,
> and found no way to jclouds BlobStore to work on the current GAE Java flavor
> v1.9.18.
> When attempting to use the "BlobStore.putBlob()" method, I get this
> {noformat}
> java.lang.SecurityException: java.lang.IllegalAccessException: Reflection is
> not allowed on java.lang.String(int,int,char[])
> at com.google.appengine.runtime.Request.process-6c82fef5146f94d9(Request.java)
> at java.lang.reflect.Constructor.setAccessible(Constructor.java:40)
> at org.jclouds.reflect.Reflection2$1.load(Reflection2.java:156)
> at org.jclouds.reflect.Reflection2$1.load(Reflection2.java:152)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3527)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2319)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2282)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2197)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
> at org.jclouds.reflect.Reflection2.get(Reflection2.java:345)
> at org.jclouds.reflect.Reflection2.constructors(Reflection2.java:99)
> at
> org.jclouds.json.internal.NamingStrategies$AnnotationConstructorNamingStrategy.getDeserializer(NamingStrategies.java:248)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory.create(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:122)
> at com.google.gson.Gson.getAdapter(Gson.java:358)
> at
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getFieldAdapter(ReflectiveTypeAdapterFactory.java:109)
> at
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.access$100(ReflectiveTypeAdapterFactory.java:46)
> at
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.(ReflectiveTypeAdapterFactory.java:84)
> at
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:83)
> at
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:129)
> at
> com.google.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:75)
> at com.google.gson.Gson.getAdapter(Gson.java:358)
> at com.google.gson.Gson.toJson(Gson.java:587)
> at com.google.gson.Gson.toJson(Gson.java:574)
> at com.google.gson.Gson.toJson(Gson.java:529)
> at com.google.gson.Gson.toJson(Gson.java:509)
> at org.jclouds.json.internal.GsonWrapper.toJson(GsonWrapper.java:52)
> at
> org.jclouds.googlecloudstorage.binders.MultipartUploadBinder.bindToRequest(MultipartUploadBinder.java:53)
> at
> org.jclouds.rest.internal.RestAnnotationProcessor.apply(RestAnnotationProcessor.java:324)
> at
> org.jclouds.rest.internal.RestAnnotationProcessor.apply(RestAnnotationProcessor.java:129)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.toCommand(InvokeHttpMethod.java:188)
> at org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:84)
> at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:73)
> at org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:44)
> at
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
> at
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:87)
> at com.sun.proxy.$Proxy62.multipartUpload(Unknown Source)
> at
>
[jira] [Commented] (JCLOUDS-1516) First putblob should be signed with specific region rather than with default region during createcontainer API
[ https://issues.apache.org/jira/browse/JCLOUDS-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378380#comment-17378380 ] ASF subversion and git services commented on JCLOUDS-1516: -- Commit 779bc2db19dd36f40cb5668c2c41620f0e74b8c4 in jclouds's branch refs/heads/master from didixith [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=779bc2d ] JCLOUDS-1516: specify host name when creating bucket > First putblob should be signed with specific region rather than with default > region during createcontainer API > --- > > Key: JCLOUDS-1516 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1516 > Project: jclouds > Issue Type: New Feature > Components: jclouds-blobstore >Affects Versions: 2.1.2 > Environment: Linux >Reporter: Dileep Dixith >Priority: Major > Original Estimate: 24h > Remaining Estimate: 24h > > When container in non default region exists, only first time put operation > will be applied to find out whether bucket exists and have proper access or > not. Aws sigv4 signature will be created based on the default region only as > create bucket method was not honoring the region specified. > So, Put request was first signed with default region and if the user does not > have access to default(us-east-1) region,. Then it will be re-directed to > sa-east-1 region, but the request is signed with us-east-1, the request is > rejected and throws "The authorization header is malformed". > Flow in case of user has access to default region: > 17:22:24.460 [bscThread-02] DEBUG o.j.rest.internal.InvokeHttpMethod - >> > invoking CreateBucket > 17:22:24.460 [bscThread-02] DEBUG o.j.rest.internal.InvokeHttpMethod - >> > invoking CreateBucket > 17:22:24.461 [bscThread-02] DEBUG jclouds.signature - << PUT > / > content-length:105 > content-type:text/xml > host:test3.s3.amazonaws.com > x-amz-content-sha256:f5d7dd57e1e23b516fc3543b9f24fc19a8409557905f48c6f412b3a67946ce96 > x-amz-date:20190818T115218Z > content-length;content-type;host;x-amz-content-sha256;x-amz-date > f5d7dd57e1e23b516fc3543b9f24fc19a8409557905f48c6f412b3a67946ce96 > 17:22:24.461 [bscThread-02] DEBUG jclouds.signature - << AWS4-HMAC-SHA256 > 20190818T115218Z > 20190818/us-east-1/s3/aws4_request > 089a5248f5eff6e8b6378154acdf07bff7d208029c98c67af44c99b4a8f2df39 > 17:22:24.463 [bscThread-02] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService - > Sending request -1533211628: PUT https://test3.s3.amazonaws.com/ HTTP/1.1 > 17:22:24.463 [bscThread-02] DEBUG jclouds.wire - >> > "sa-east-1" > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> PUT > https://test3.s3.amazonaws.com/ HTTP/1.1 > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> Content-Type: text/xml > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> Content-Length: 105 > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> Host: > test3.s3.amazonaws.com > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> x-amz-content-sha256: > f5d7dd57e1e23b516fc3543b9f24fc19a8409557905f48c6f412b3a67946ce96 > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> X-Amz-Date: > 20190818T115218Z > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> Authorization: > AWS4-HMAC-SHA256 > Credential=AKIAIGKQ7V52FQQJFYJQ/20190818/us-east-1/s3/aws4_request, > SignedHeaders=content-length;content-type;host;x-amz-content-sha256;x-amz-date, > Signature=637d42fbf6684430ab0f08fd82cbae69f3261859e0031ad40054bccb829473da > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> Content-Type: text/xml > 17:22:24.464 [bscThread-02] DEBUG jclouds.headers - >> Content-Length: 105 > 17:22:25.671 [bscThread-02] DEBUG o.j.h.i.JavaUrlHttpCommandExecutorService - > Receiving response -1533211628: HTTP/1.1 409 Conflict > 17:22:25.671 [bscThread-02] DEBUG jclouds.headers - << HTTP/1.1 409 Conflict > 17:22:25.672 [bscThread-02] DEBUG jclouds.headers - << Transfer-Encoding: > chunked > 17:22:25.672 [bscThread-02] DEBUG jclouds.headers - << Server: AmazonS3 > 17:22:25.672 [bscThread-02] DEBUG jclouds.headers - << x-amz-request-id: > 09E5163C51F25F34 > 17:22:25.673 [bscThread-02] DEBUG jclouds.headers - << x-amz-id-2: > WuN84GYMs47Nn6+48XYDpLZNvp0NPszokKyhxlzZk+ub8RhjbLpkfEI8E2tKWVCFKtJiXrhdpkc= > 17:22:25.673 [bscThread-02] DEBUG jclouds.headers - << Date: Sun, 18 Aug 2019 > 11:52:11 GMT > 17:22:25.673 [bscThread-02] DEBUG jclouds.headers - << x-amz-bucket-region: > sa-east-1 > 17:22:25.673 [bscThread-02] DEBUG jclouds.headers - << Content-Type: > application/xml > 17:22:25.673 [bscThread-02] DEBUG jclouds.wire - << " encoding="UTF-8"?>[\n]" > 17:22:25.673 [bscThread-02] DEBUG jclouds.wire - << > "BucketAlreadyOwnedByYouYour previous request to > create the named bucket succeeded and
[jira] [Commented] (JCLOUDS-1581) NullPointerException when parsing Cors object for GCE list buckets request
[
https://issues.apache.org/jira/browse/JCLOUDS-1581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371753#comment-17371753
]
ASF subversion and git services commented on JCLOUDS-1581:
--
Commit fda1824620e2c448bbb0cec33c568632be8bfe6f in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=fda1824 ]
JCLOUDS-1581: Make CORS maxAgeSeconds optional
This field is not required:
https://cloud.google.com/storage/docs/cross-origin#cors-elements
> NullPointerException when parsing Cors object for GCE list buckets request
> --
>
> Key: JCLOUDS-1581
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1581
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.3.0
>Reporter: Lukasz Rek
>Assignee: Andrew Gaul
>Priority: Major
> Labels: google-cloud-storage
> Fix For: 2.4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> NullPointerException is thrown when requesting
> GoogleCloudStorageBlobStore.list for specific buckets.
> Stack trace:
> {code:java}
> java.lang.NullPointerException: Null maxAgeSeconds
> at
> org.jclouds.googlecloudstorage.domain.AutoValue_Bucket_Cors.(AutoValue_Bucket_Cors.java:33)
> at
> org.jclouds.googlecloudstorage.domain.Bucket$Cors.create(Bucket.java:52)
> at jdk.internal.reflect.GeneratedMethodAccessor188.invoke(Unknown
> Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> com.google.common.reflect.Invokable$MethodInvokable.invokeInternal(Invokable.java:200)
> at com.google.common.reflect.Invokable.invoke(Invokable.java:101)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.newInstance(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:227)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:207)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.readAndBuild(NullFilteringTypeAdapterFactories.java:96)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:84)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:63)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$ParameterReader.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:275)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:187)
> at
> org.jclouds.googlecloud.config.ListPageAdapterFactory$ListPageAdapter.readItems(ListPageAdapterFactory.java:73)
> at
> org.jclouds.googlecloud.config.ListPageAdapterFactory$ListPageAdapter.read(ListPageAdapterFactory.java:56)
> at
> org.jclouds.googlecloud.config.ListPageAdapterFactory$ListPageAdapter.read(ListPageAdapterFactory.java:36)
> at com.google.gson.Gson.fromJson(Gson.java:932)
> at com.google.gson.Gson.fromJson(Gson.java:897)
> at org.jclouds.json.internal.GsonWrapper.fromJson(GsonWrapper.java:56)
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:83)
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:77)
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:62)
> at org.jclouds.http.functions.ParseJson.apply(ParseJson.java:42)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:91)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:74)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:45)
> at
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
> at
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:86)
> at com.sun.proxy.$Proxy231.listBucket(Unknown Source)
> at
> org.jclouds.googlecloudstorage.blobstore.GoogleCloudStorageBlobStore.list(GoogleCloudStorageBlobStore.java:119)
> {code}
>
> Bucket that is causing exception has following configuration (i removed ids
> from json):
> {code:java}
> {
> "kind":
[jira] [Commented] (JCLOUDS-1577) Running custom image created from MS Marketplace fails because no "Plan Information" is provided
[
https://issues.apache.org/jira/browse/JCLOUDS-1577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17371736#comment-17371736
]
ASF subversion and git services commented on JCLOUDS-1577:
--
Commit 261f9d1fd5c190e9c11a9d65968693cee3df4008 in jclouds's branch
refs/heads/master from Miroslav Novak
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=261f9d1 ]
JCLOUDS-1577 - Allow to provide Azure Plan Information when starting custom
image based on Azure Marketplace image.
> Running custom image created from MS Marketplace fails because no "Plan
> Information" is provided
>
>
> Key: JCLOUDS-1577
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1577
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.3.0
>Reporter: Miroslav Novak
>Priority: Major
> Labels: azurecompute-arm, compute
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This issue is specific for Azure ARM.
> New VM based on RHEL 8 "gold" image on MS Marketplace can be easily started.
> However in case I create new custom image from modified VM (installing some
> application and making changes to firewall) and try to start again then it
> fails because "Plan Information" was not provided. Basically when new VM is
> started from this image publisher/offer/sku is required.
> As the new image is custom there is no way how to pass publisher/offer/sku
> properties to JClouds when creating new VM.
> Failure message:
> {code}
> Provisioning state Provisioning failed.
> Creating a virtual machine from Marketplace image or a custom image sourced
> from a Marketplace image requires Plan information in the request. VM:
> '/subscriptions/7dee6f21-9f05-414e-99fa-08d3215fb420/resourceGroups/eap73-rhel8-byos/providers/Microsoft.Compute/virtualMachines/sst-mnovak-138'..
> VMMarketplaceInvalidInput
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1580) BlobStore.blobMetadata().getUserMetadata() returns empty Map when cloud provider returns lowercase metadata headers
[
https://issues.apache.org/jira/browse/JCLOUDS-1580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17367793#comment-17367793
]
ASF subversion and git services commented on JCLOUDS-1580:
--
Commit 2791f470466493a3f10ce0d4fb53416056d407cc in jclouds's branch
refs/heads/master from i831992
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=2791f47 ]
JCLOUDS-1580 - Add support for lowercase metadata headers
The issue happens if a cloud provider returns lowercase metadata headers, for
example: "x-object-meta-apiversion" instead of "X-Object-Meta-ApiVersion"
In that case, BlobStore.blobMetadata(CONTAINER, PATH).getUserMetadata()
incorrectly returns an empty map.
This happens because the code is looking for the exact String "-Meta-"
(case-sensitive).
This checkin allows to handle metadata headers of any case, and also adds a
unit test for that situation.
> BlobStore.blobMetadata().getUserMetadata() returns empty Map when cloud
> provider returns lowercase metadata headers
> ---
>
> Key: JCLOUDS-1580
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1580
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.3.0
>Reporter: Erik Ebert
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I believe this is happening because jclouds/swift is specifically looking for
> user metadata with the prefix "X-Object-Meta-", case SENSITIVE:
> X-Object-Meta-foo
>
> But since header names are case-INSENSITIVE. per RFC 2616, this fails if the
> cloud provider returns header names in lower case:
> x-object-meta-foo
>
> I discovered this while using "openstack-swift" to access SAP's Converged
> Cloud, but it would affect any cloud provider that returns lower-case header
> names.
>
> In my case, this is an example of what is returned by Converged Cloud:
> curl --head -H "X-Auth-Token:"
> HTTP/1.1 200 OK
> content-type: application/octet-stream
> *x-object-meta-original-created-time*: 1623984822180
> *x-object-meta-content-md5*: rREHajOaHzUiU8DQoap9NA==
> etag: x
> last-modified: Fri, 18 Jun 2021 02:53:53 GMT
> x-timestamp: 1623984832.86825
> accept-ranges: bytes
> content-length: 12
> x-trans-id:
> x-openstack-request-id: x
> date: Fri, 18 Jun 2021 03:16:46 GMT
>
> Sample jclouds code:
>
> {code:java}
> BlobStoreContext blobStoreContext =
> ContextBuilder.newBuilder("openstack-swift")
> .endpoint(ENDPOINT)
> .credentials(INDENTITY, CREDENTIAL)
> .overrides(overrides)
> .buildApi(BlobStoreContext.class);
> BlobStore blobStore = blobStoreContext.getBlobStore();
> BlobMetadata blobMetadata = blobStore.blobMetadata(CONTAINER, PATH);
> Map userMetadata = blobMetadata.getUserMetadata()
> System.out.println(userMetadata.toString())
>
> {code}
>
> blobMetadata.getUserMetadata() SHOULD return something like:
> *original-created-time*: 1623984822180
> *content-md5*: rREHajOaHzUiU8DQoap9NA==
> (or similar), but instead it returns an empty Map object.
>
> Stepping through the code, I believe the source of the problem is line 41 of
> EntriesWithoutMetaPrefix.java:
> [https://github.com/apache/jclouds/blob/0b89ee0825d45de1193090cdd5efc5f1135fa200/apis/openstack-swift/src/main/java/org/jclouds/openstack/swift/v1/functions/EntriesWithoutMetaPrefix.java]
>
> Partial stack trace from the code example above:
> {code:java}
> at
> org.jclouds.openstack.swift.v1.functions.EntriesWithoutMetaPrefix.apply(EntriesWithoutMetaPrefix.java:41)
> at
> org.jclouds.openstack.swift.v1.functions.ParseObjectFromResponse.apply(ParseObjectFromResponse.java:81)
> at
> org.jclouds.openstack.swift.v1.functions.ParseObjectFromResponse.apply(ParseObjectFromResponse.java:41)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:91)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:74)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.apply(InvokeHttpMethod.java:45)
> at
> org.jclouds.reflect.FunctionalReflection$FunctionalInvocationHandler.handleInvocation(FunctionalReflection.java:117)
> at
> com.google.common.reflect.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:86)
> at com.sun.proxy.$Proxy199.getWithoutBody(Unknown Source:-1)
> {code}
>
> I believe the fix would be to change line 41 of EntriesWithoutMetaPrefix.java
> from
> int index = header.getKey().indexOf("\-Meta\-");
> to something like:
> int index = header.getKey()*.toLowerCase()*.indexOf("*\-meta\-*");
>
> {code:java}
> 41c41
> < int index = header.getKey().indexOf("-Meta-");
> ---
> > int index = header.getKey().toLowerCase().indexOf("-meta-");
> {code}
--
This message
[jira] [Commented] (JCLOUDS-1572) Update GCS bucket regions
[ https://issues.apache.org/jira/browse/JCLOUDS-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17311990#comment-17311990 ] ASF subversion and git services commented on JCLOUDS-1572: -- Commit c995a04fe90b20b621af18fdf1674d3245d2a50e in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=c995a04 ] JCLOUDS-1572: Update GCS bucket regions > Update GCS bucket regions > - > > Key: JCLOUDS-1572 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1572 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.3.0 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Minor > Labels: google-cloud-storage > > https://cloud.google.com/storage/docs/locations -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1551) Update version of OkHttp
[
https://issues.apache.org/jira/browse/JCLOUDS-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17283573#comment-17283573
]
ASF subversion and git services commented on JCLOUDS-1551:
--
Commit 44ff69d144ff4fa0fa980cfba0d2c14fd9175f85 in jclouds's branch
refs/heads/master from korlov42
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=44ff69d ]
JCLOUDS-1551: Update version of OkHttp 3.14.9
> Update version of OkHttp
>
>
> Key: JCLOUDS-1551
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1551
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-drivers
>Affects Versions: 2.2.1
>Reporter: Konstantin Orlov
>Priority: Major
> Labels: dependency
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Current version of {{OkHttp}} (ver 2.2.0) has [a vulnerability of medium
> severity|https://nvd.nist.gov/vuln/detail/CVE-2016-2402]. It would nice to
> bump the version to get rid of this vulnerability.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1557) Azure Blob Storage: Support for Local Endpoints (eg Azurite)
[
https://issues.apache.org/jira/browse/JCLOUDS-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245619#comment-17245619
]
ASF subversion and git services commented on JCLOUDS-1557:
--
Commit 17fd80cd5a10ed2ab6886ad436f51b62ad0a826d in jclouds's branch
refs/heads/master from davidsloan
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=17fd80c ]
JCLOUDS-1557 - Azure local server support
Co-authored-by: David Sloan
> Azure Blob Storage: Support for Local Endpoints (eg Azurite)
>
>
> Key: JCLOUDS-1557
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1557
> Project: jclouds
> Issue Type: Improvement
>Reporter: Dave Sloan
>Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Azurite provides a local Azure-compatible endpoint for purposes of testing
> without requiring network traffic or incurring costs on Azure.
> Currently while it is possible to define a custom endpoint this is not
> respected.
> In both
> [https://github.com/apache/jclouds/blob/ba1504b38e725c45db304767ac76b2be4b71fd0d/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/AzureBlobRequestSigner.java#L66]
> [https://github.com/apache/jclouds/blob/ca5190636a5fc1ffe48d0d6b8087ad160c0b7d80/providers/azureblob/src/main/java/org/jclouds/azure/storage/filters/SharedKeyLiteAuthentication.java#L95]
>
> The `storageUrl` is hard-coded to the Azure location
> {code:java}
> this.storageUrl = URI.create("https://; + creds.get().identity +
> ".blob.core.windows.net/");
> {code}
>
> This should be made to respect a custom endpoint if configured, e.g.
>
> {code:java}
> BlobStoreContext context = ContextBuilder.newBuilder("azureblob")
> .credentials(storageAccountName, storageAccountKey)
> .endpoint("http://localhost:1;)
> .buildView(BlobStoreContext.class);
> {code}
> In addition, similar to the AWS S3 connector (`enableVirtualHostBuckets`), a
> configurable property should be provided to change the format of the URLs
> used by Azure to include the storage account name in the path.
>
>
> *Azure endpoint URL format (storage account in hostname)*
> [https://devstoreaccount1.blob.core.windows.net/]
>
> *Azurite endpoint URL format (**storage account* *in path)*
> [http://localhost:1/devstoreaccount1/]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1559) ParseJson is using the system's default charset to parse HTTP responses
[ https://issues.apache.org/jira/browse/JCLOUDS-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244500#comment-17244500 ] ASF subversion and git services commented on JCLOUDS-1559: -- Commit 2e9ae3b3af1c94f7931b15f7d1cfb87bdf141ab8 in jclouds-labs's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds-labs.git;h=2e9ae3b ] JCLOUDS-1559: Add explicit Charset to fromJson calls > ParseJson is using the system's default charset to parse HTTP responses > --- > > Key: JCLOUDS-1559 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1559 > Project: jclouds > Issue Type: Bug >Reporter: roded >Assignee: Andrew Gaul >Priority: Major > Fix For: 2.3.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > ParseJson is using the system's default charset to parse HTTP responses. > HTTP response JSON parsing then fails on systems whose default charset is not > UTF8. > ParseJson should specify explicitly that UTF8 should be used to parse the > HTTP responses. Json's fromJson methods should accept a charset argument. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1559) ParseJson is using the system's default charset to parse HTTP responses
[ https://issues.apache.org/jira/browse/JCLOUDS-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17244468#comment-17244468 ] ASF subversion and git services commented on JCLOUDS-1559: -- Commit 3a7e41f4e2e577b60430a7199cc4ddd1dfeadb62 in jclouds's branch refs/heads/master from roded [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=3a7e41f ] JCLOUDS-1559: add Charset to Json.fromJson InputStream methods > ParseJson is using the system's default charset to parse HTTP responses > --- > > Key: JCLOUDS-1559 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1559 > Project: jclouds > Issue Type: Bug >Reporter: roded >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > ParseJson is using the system's default charset to parse HTTP responses. > HTTP response JSON parsing then fails on systems whose default charset is not > UTF8. > ParseJson should specify explicitly that UTF8 should be used to parse the > HTTP responses. Json's fromJson methods should accept a charset argument. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1498) Upgrade to recent Guice version
[ https://issues.apache.org/jira/browse/JCLOUDS-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202535#comment-17202535 ] ASF subversion and git services commented on JCLOUDS-1498: -- Commit 31a3e5b5df1543d04098e3a694130b7ae8e6e079 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=31a3e5b ] JCLOUDS-1498: Upgrade to Guice 4.2.3 Release notes: https://github.com/google/guice/wiki/Guice423 > Upgrade to recent Guice version > --- > > Key: JCLOUDS-1498 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1498 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 2.1.1, 2.1.2 >Reporter: Sharon Ben Asher >Priority: Critical > Labels: dependency > Time Spent: 0.5h > Remaining Estimate: 0h > > We are using jclouds version 2.1.1 (nova, gcp storage, rackspace) > Jclouds is using Guice version 3.0, released circa 2011. > This version has incompatibilities with Guice version 4.x, causing runtime > exceptions such as the one listed below. we cannot upgrade many of our > library dependencies because of that > java.lang.ExceptionInInitializerError > at com.valooto.storage.StorageSingleton.getInstance(StorageSingleton.java:31) > ... > Caused by: com.google.inject.CreationException: Unable to create injector, > see the following errors: > 1) Error in custom provider, java.lang.NoSuchMethodError: > com.google.common.util.concurrent.MoreExecutors.newDirectExecutorService()Lcom/google/common/util/concurrent/ListeningExecutorService; > at > org.jclouds.openstack.keystone.auth.config.AuthenticationModule.provideAuthenticationMethods(AuthenticationModule.java:98) > at > org.jclouds.openstack.keystone.auth.config.AuthenticationModule.provideAuthenticationMethods(AuthenticationModule.java:98) > while locating java.util.Map com.google.common.base.Function org.jclouds.openstack.keystone.auth.domain.AuthInfo>> > for the 2nd parameter of > org.jclouds.openstack.keystone.auth.config.AuthenticationModule.authenticationMethodForCredentialType(AuthenticationModule.java:114) > at > org.jclouds.openstack.keystone.auth.config.AuthenticationModule.authenticationMethodForCredentialType(AuthenticationModule.java:114) > while locating > com.google.common.base.Function org.jclouds.openstack.keystone.auth.domain.AuthInfo> > for the 1st parameter of > org.jclouds.openstack.keystone.auth.config.AuthenticationModule.provideAuthInfoCache(AuthenticationModule.java:125) > at > org.jclouds.openstack.keystone.auth.config.AuthenticationModule.provideAuthInfoCache(AuthenticationModule.java:125) > while locating > com.google.common.cache.LoadingCache org.jclouds.openstack.keystone.auth.domain.AuthInfo> > for the 1st parameter of > org.jclouds.openstack.keystone.auth.handlers.RetryOnRenew.(RetryOnRenew.java:62) > at > org.jclouds.openstack.keystone.auth.handlers.RetryOnRenew.class(RetryOnRenew.java:48) > while locating org.jclouds.openstack.keystone.auth.handlers.RetryOnRenew > while locating org.jclouds.http.HttpRetryHandler annotated with interface > org.jclouds.http.annotation.ClientError > Caused by: java.lang.NoSuchMethodError: > com.google.common.util.concurrent.MoreExecutors.newDirectExecutorService()Lcom/google/common/util/concurrent/ListeningExecutorService; > at > org.jclouds.lifecycle.config.LifeCycleModule$4$1.afterInjection(LifeCycleModule.java:120) > at > com.google.inject.internal.MembersInjectorImpl.notifyListeners(MembersInjectorImpl.java:119) > at > com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:121) > at > com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:90) > at > com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:268) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) > at com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:194) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) > at com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1019) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092) > at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1015) > at > com.google.inject.internal.InjectorImpl.getInstance(InjectorImpl.java:1054) > at >
[jira] [Commented] (JCLOUDS-1552) AWSError#parseAWSErrorFromContent attempts to parse the response even if there is none
[
https://issues.apache.org/jira/browse/JCLOUDS-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199399#comment-17199399
]
ASF subversion and git services commented on JCLOUDS-1552:
--
Commit 619466c66ff5752d5c8c12b2bd1397e8fd6be9d7 in jclouds's branch
refs/heads/2.2.x from Tamas Cservenak
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=619466c ]
JCLOUDS-1552: Do not attempt to parse empty payload (#82)
> AWSError#parseAWSErrorFromContent attempts to parse the response even if
> there is none
> --
>
> Key: JCLOUDS-1552
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1552
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.1
>Reporter: Tamás Cservenák
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> With S3 BlobStore request, asking HEAD of non existent object (below request
> dumped from debug) gets a response with 404 and no XML body, but AWSUtil
> still tries (and fails) to parse the error from response, filling up log with
> noise.
> S3 Server is Minio:
> request:
> {noformat}
> {method=HEAD,
> endpoint=http://127.0.0.1:9000/px01-bkt-0579/pointer/public/64/64099abcf2dd581576d8081778110a245eff311d,
> headers={}} {noformat}
> response:
> {noformat}
> {statusCode=404, message=Not Found, headers={Accept-Ranges=[bytes],
> Content-Security-Policy=[block-all-mixed-content],
> Server=[MinIO/RELEASE.2020-09-08T23-05-18Z], Vary=[Origin],
> X-Amz-Request-Id=[1633B89A38D5D1CC], X-Xss-Protection=[1; mode=block],
> Date=[Fri, 11 Sep 2020 11:54:25 GMT]}, payload=[content=true,
> contentMetadata=[cacheControl=null, contentDisposition=null,
> contentEncoding=null, contentLanguage=null, contentLength=0, contentMD5=null,
> contentType=application/unknown, expires=null], written=false,
> isSensitive=false]} {noformat}
> So, payload is there (is not null), but content length is clearly 0. Still,
> org.jclouds.aws.util.AWSUtils#parseAWSErrorFromContent does something like
> this:
> {noformat}
> if (response.getPayload() == null) {
> return null;
> } else if
> ("text/plain".equals(response.getPayload().getContentMetadata().getContentType()))
> {
> return null;
> } else {
> .. parse
> } {noformat}
> Why not check in first IF branch, is payload == null OR payload length is
> zero?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1552) AWSError#parseAWSErrorFromContent attempts to parse the response even if there is none
[
https://issues.apache.org/jira/browse/JCLOUDS-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199398#comment-17199398
]
ASF subversion and git services commented on JCLOUDS-1552:
--
Commit d65047c87b46717605742057b59847673339e8fe in jclouds's branch
refs/heads/master from Tamas Cservenak
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=d65047c ]
JCLOUDS-1552: Do not attempt to parse empty payload (#82)
> AWSError#parseAWSErrorFromContent attempts to parse the response even if
> there is none
> --
>
> Key: JCLOUDS-1552
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1552
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.1
>Reporter: Tamás Cservenák
>Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> With S3 BlobStore request, asking HEAD of non existent object (below request
> dumped from debug) gets a response with 404 and no XML body, but AWSUtil
> still tries (and fails) to parse the error from response, filling up log with
> noise.
> S3 Server is Minio:
> request:
> {noformat}
> {method=HEAD,
> endpoint=http://127.0.0.1:9000/px01-bkt-0579/pointer/public/64/64099abcf2dd581576d8081778110a245eff311d,
> headers={}} {noformat}
> response:
> {noformat}
> {statusCode=404, message=Not Found, headers={Accept-Ranges=[bytes],
> Content-Security-Policy=[block-all-mixed-content],
> Server=[MinIO/RELEASE.2020-09-08T23-05-18Z], Vary=[Origin],
> X-Amz-Request-Id=[1633B89A38D5D1CC], X-Xss-Protection=[1; mode=block],
> Date=[Fri, 11 Sep 2020 11:54:25 GMT]}, payload=[content=true,
> contentMetadata=[cacheControl=null, contentDisposition=null,
> contentEncoding=null, contentLanguage=null, contentLength=0, contentMD5=null,
> contentType=application/unknown, expires=null], written=false,
> isSensitive=false]} {noformat}
> So, payload is there (is not null), but content length is clearly 0. Still,
> org.jclouds.aws.util.AWSUtils#parseAWSErrorFromContent does something like
> this:
> {noformat}
> if (response.getPayload() == null) {
> return null;
> } else if
> ("text/plain".equals(response.getPayload().getContentMetadata().getContentType()))
> {
> return null;
> } else {
> .. parse
> } {noformat}
> Why not check in first IF branch, is payload == null OR payload length is
> zero?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1367) Blob.getPayload.openStream() is inconsistent across implementations
[ https://issues.apache.org/jira/browse/JCLOUDS-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17169263#comment-17169263 ] ASF subversion and git services commented on JCLOUDS-1367: -- Commit 9c21bf2cc2af3d9f45542285f278d1b85f700f2a in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=9c21bf2 ] JCLOUDS-1367: Do not open open InputStream in copyBlob This avoids an unneeded call to ByteStreams2.toByteArrayAndClose in getBlob for range requests and elides a large memory allocation. > Blob.getPayload.openStream() is inconsistent across implementations > --- > > Key: JCLOUDS-1367 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1367 > Project: jclouds > Issue Type: Bug > Components: jclouds-blobstore >Affects Versions: 2.1.0 >Reporter: Rishab Manocha >Assignee: Andrew Gaul >Priority: Minor > Labels: filesystem, transient > Fix For: 2.2.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Blob.getPayload.openStream() returns a new InputStream object if the payload > is a sub type of InputStream but returns the same stream if the payload is > of type InputStream. > It would be desirable to have it return a new Stream object which can be read > independently. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1542) Java 11 warns of illegal reflective access
[
https://issues.apache.org/jira/browse/JCLOUDS-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17151669#comment-17151669
]
ASF subversion and git services commented on JCLOUDS-1542:
--
Commit 9e4c7a16daeb97f9b51b9077e40d12ce5343840f in jclouds's branch
refs/heads/master from Jean-Noël Rouvignac
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=9e4c7a1 ]
JCLOUDS-1542 follow-up: check whether isAccessible() is already set (#79)
AccessibleObject.canAccess() would be much much better,
but this API can only be used from Java 9 onward.
> Java 11 warns of illegal reflective access
> --
>
> Key: JCLOUDS-1542
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1542
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-core
>Affects Versions: 2.2.0
>Reporter: ctranxuan
>Priority: Major
> Fix For: 2.3.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> When using JClouds BlobStore for Google Cloud Storage with Java 11, some
> warning are displayed by the JVM about illegal reflective access:
>
> {quote}WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.jclouds.reflect.Reflection2$1
> ([file:/.../jclouds-core.jar|file:///.../jclouds-core.jar]) to constructor
> java.lang.String(char[],int,int,java.lang.Void)
> WARNING: Please consider reporting this to the maintainers of
> org.jclouds.reflect.Reflection2$1
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> {quote}
>
> JClouds works but as stated, these illegal reflective accesses may be denied
> in upper Java versions.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1542) Java 11 warns of illegal reflective access
[ https://issues.apache.org/jira/browse/JCLOUDS-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17146545#comment-17146545 ] ASF subversion and git services commented on JCLOUDS-1542: -- Commit 238c97507816606a0aeca2fafd7a3196bfb7f1dc in jclouds's branch refs/heads/master from Jean-Noël Rouvignac [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=238c975 ] JCLOUDS-1542 Java 11 warns of illegal reflective access (#76) With Java 11, an illegal reflective access is output for the google cloud storage blobstore. WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.jclouds.reflect.Reflection2$1 (file:/.../jclouds-core.jar) to constructor java.lang.String(char[],int,int,java.lang.Void) WARNING: Please consider reporting this to the maintainers of org.jclouds.reflect.Reflection2$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Indeed, JClouds calls `setAccessible(true)` on the package protected constructor `java.lang.String(char[],int,int,java.lang.Void)`. Investigating the code, it turns out it is looking for constructors annotated with any of: * java.beans.ConstructorProperties * org.jclouds.json.SerializedNames * com.google.inject.Inject But `String` being defined in `java.base` module, it is impossible that it will be annotated with any of these annotation. This commit is complementary to JClouds commit db4e4af931ef19f582b85f02efb93e50f1c5d01c . Reflection2.java: Do not call `setAccessible(true)` on core java constructors and methods. For reference, here is the stacktrace of this illegal access warning: java.lang.String.(String.java:3208) java.lang.String.(String.java:251) java.util.StringJoiner.compactElts(StringJoiner.java:250) java.util.StringJoiner.toString(StringJoiner.java:173) jdk.internal.module.IllegalAccessLogger.loudWarning(IllegalAccessLogger.java:339) jdk.internal.module.IllegalAccessLogger.log(IllegalAccessLogger.java:288) jdk.internal.module.IllegalAccessLogger.log(IllegalAccessLogger.java:261) jdk.internal.module.IllegalAccessLogger.logIfOpenedForIllegalAccess(IllegalAccessLogger.java:226) java.lang.reflect.AccessibleObject.logIfOpenedForIllegalAccess(AccessibleObject.java:366) java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:325) java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280) java.lang.reflect.Constructor.checkCanSetAccessible(Constructor.java:189) java.lang.reflect.Constructor.setAccessible(Constructor.java:182) org.jclouds.reflect.Reflection2$1.load(Reflection2$1.java:157) org.jclouds.reflect.Reflection2$1.load(Reflection2$1.java:153) com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache$LoadingValueReference.java:3529) com.google.common.cache.LocalCache$Segment.loadSync(LocalCache$Segment.java:2278) com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache$Segment.java:2155) com.google.common.cache.LocalCache$Segment.get(LocalCache$Segment.java:2045) com.google.common.cache.LocalCache.get(LocalCache.java:3953) com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3976) com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache$LocalLoadingCache.java:4960) org.jclouds.reflect.Reflection2.get(Reflection2.java:346) org.jclouds.reflect.Reflection2.constructors(Reflection2.java:100) org.jclouds.json.internal.NamingStrategies$AnnotationConstructorNamingStrategy.getDeserializer(NamingStrategies$AnnotationConstructorNamingStrategy.java:271) org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory.create(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:125) com.google.gson.Gson.getAdapter(Gson.java:458) org.jclouds.json.gson.internal.bind.ReflectiveTypeAdapterFactory.createBoundField(ReflectiveTypeAdapterFactory.java:117) org.jclouds.json.gson.internal.bind.ReflectiveTypeAdapterFactory.getBoundFields(ReflectiveTypeAdapterFactory.java:166) org.jclouds.json.gson.internal.bind.ReflectiveTypeAdapterFactory.create(ReflectiveTypeAdapterFactory.java:102) com.google.gson.Gson.getAdapter(Gson.java:458) com.google.gson.Gson.toJson(Gson.java:696) com.google.gson.Gson.toJson(Gson.java:683) com.google.gson.Gson.toJson(Gson.java:638) com.google.gson.Gson.toJson(Gson.java:618) org.jclouds.json.internal.GsonWrapper.toJson(GsonWrapper.java:65) org.jclouds.oauth.v2.functions.ClaimsToAssertion.apply(ClaimsToAssertion.java:59) org.jclouds.oauth.v2.functions.ClaimsToAssertion.apply(ClaimsToAssertion.java:43)
[jira] [Commented] (JCLOUDS-1333) Cannot compile jclouds with Guava 21+
[
https://issues.apache.org/jira/browse/JCLOUDS-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144824#comment-17144824
]
ASF subversion and git services commented on JCLOUDS-1333:
--
Commit 5c62466a4233923dcc908ef7afe78367b098eaab in jclouds-labs-aws's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds-labs-aws.git;h=5c62466 ]
JCLOUDS-1333: Fix Guava 21 issues
> Cannot compile jclouds with Guava 21+
> -
>
> Key: JCLOUDS-1333
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1333
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-core
>Affects Versions: 2.1.0
>Reporter: Andrew Gaul
>Assignee: Andrew Gaul
>Priority: Major
> Labels: guava
> Fix For: 2.3.0
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> jclouds has compatibility with Guava 18-22 but we cannot compile using 21+
> due to some kind of Guava vs Java 8 Function class type error:
> {noformat}
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:102:
> error: method compose in interface java.util.function.Function cannot
> be applied to given types;
> transformer = compose(Function.class.cast(wrappingTransformer),
> transformer);
>^
> required: java.util.function.Function
> found:
> com.google.common.base.Function,com.google.common.base.Function
> reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
> where V,T,R are type-variables:
> V extends Object declared in method
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
> where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:189:
> error: method compose in interface java.util.function.Function cannot
> be applied to given types;
> transformer = compose(new OnlyElementOrNull(), transformer);
> ^
> required: java.util.function.Function
> found:
> OnlyElementOrNull,com.google.common.base.Function
> reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
> where V,T,R are type-variables:
> V extends Object declared in method
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
> where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> {noformat}
> This does not affect applications from using Guava 21-22 but does impact our
> compatibility testing. Note that you need to set {{maven.compile.source}} to
> 1.8 to test Guava 21+.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1473) S3 intelligent tiering
[ https://issues.apache.org/jira/browse/JCLOUDS-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144547#comment-17144547 ] ASF subversion and git services commented on JCLOUDS-1473: -- Commit 8762fbaf8efca5568c32b8e74b0dac1297b3f59b in jclouds's branch refs/heads/master from Sam Ottenhoff [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=8762fba ] JCLOUDS-1473 add INTELLIGENT_TIERING enum > S3 intelligent tiering > -- > > Key: JCLOUDS-1473 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1473 > Project: jclouds > Issue Type: New Feature > Components: jclouds-blobstore >Affects Versions: 2.1.1 >Reporter: Andrew Gaul >Priority: Minor > Labels: s3 > Time Spent: 20m > Remaining Estimate: 0h > > Recently announced: > > https://aws.amazon.com/blogs/aws/new-automatic-cost-optimization-for-amazon-s3-via-intelligent-tiering/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1334) Guava 23.0 incompatibility: missing SimpleTimeLimiter constructor
[ https://issues.apache.org/jira/browse/JCLOUDS-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144476#comment-17144476 ] ASF subversion and git services commented on JCLOUDS-1334: -- Commit 62767a14610fc1c97c440dbd5ee0f02b276a1069 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=62767a1 ] JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22 This allows compatibility with Guava 29. Also unwind some older workarounds. > Guava 23.0 incompatibility: missing SimpleTimeLimiter constructor > - > > Key: JCLOUDS-1334 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1334 > Project: jclouds > Issue Type: Bug > Components: jclouds-core >Reporter: Tim Peierls >Assignee: Andrew Gaul >Priority: Minor > Labels: guava > Fix For: 2.1.0 > > Original Estimate: 24h > Remaining Estimate: 24h > > With Guava 23, the public constructor for SimpleTimeLimiter, which was > deprecated in Guava 22.0, has been removed. This constructor is used by > JClouds' ExecutorServiceModule and by some tests. > Tests won't be compiled under Guava 23, so that's not a concern, but anyone > running JClouds with Guava 23 will get a runtime error when > ExecutorServiceModule is loaded. > Easiest fix is to use reflection to call SimpleTimeLimiter.create (introduced > in Guava 22.0) if possible, and fall back to the constructor otherwise. > This was noticed after the resolution of JCLOUDS-1225, which brought > compatibility to Guava 22.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1470) Vulnarable Guava dependency dragged from jclouds-driver
[ https://issues.apache.org/jira/browse/JCLOUDS-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144477#comment-17144477 ] ASF subversion and git services commented on JCLOUDS-1470: -- Commit 62767a14610fc1c97c440dbd5ee0f02b276a1069 in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=62767a1 ] JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22 This allows compatibility with Guava 29. Also unwind some older workarounds. > Vulnarable Guava dependency dragged from jclouds-driver > --- > > Key: JCLOUDS-1470 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1470 > Project: jclouds > Issue Type: Bug > Components: jclouds-core >Affects Versions: 2.1.1 >Reporter: Blagoi Anastasov >Priority: Major > Labels: guava > > It looks like jclouds-driver drags old(from 2014) and vulnerable guava > dependency - 18.0. > [https://nvd.nist.gov/view/vuln/search-results?adv_search=true=on_version=cpe%3A%2Fa%3Agoogle%3Aguava%3A18.0] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1333) Cannot compile jclouds with Guava 21+
[
https://issues.apache.org/jira/browse/JCLOUDS-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144475#comment-17144475
]
ASF subversion and git services commented on JCLOUDS-1333:
--
Commit 62767a14610fc1c97c440dbd5ee0f02b276a1069 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=62767a1 ]
JCLOUDS-1333: JCLOUDS-1334: JCLOUDS-1470: Require Java 8 and Guava 22
This allows compatibility with Guava 29. Also unwind some older
workarounds.
> Cannot compile jclouds with Guava 21+
> -
>
> Key: JCLOUDS-1333
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1333
> Project: jclouds
> Issue Type: Improvement
> Components: jclouds-core
>Affects Versions: 2.1.0
>Reporter: Andrew Gaul
>Priority: Major
> Labels: guava
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> jclouds has compatibility with Guava 18-22 but we cannot compile using 21+
> due to some kind of Guava vs Java 8 Function class type error:
> {noformat}
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:102:
> error: method compose in interface java.util.function.Function cannot
> be applied to given types;
> transformer = compose(Function.class.cast(wrappingTransformer),
> transformer);
>^
> required: java.util.function.Function
> found:
> com.google.common.base.Function,com.google.common.base.Function
> reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
> where V,T,R are type-variables:
> V extends Object declared in method
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
> where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> /home/gaul/work/jclouds/core/src/main/java/org/jclouds/rest/internal/TransformerForRequest.java:189:
> error: method compose in interface java.util.function.Function cannot
> be applied to given types;
> transformer = compose(new OnlyElementOrNull(), transformer);
> ^
> required: java.util.function.Function
> found:
> OnlyElementOrNull,com.google.common.base.Function
> reason: cannot infer type-variable(s) V
> (actual and formal argument lists differ in length)
> where V,T,R are type-variables:
> V extends Object declared in method
> compose(java.util.function.Function)
> T extends Object declared in interface java.util.function.Function
> R extends Object declared in interface java.util.function.Function
> where CAP#1 is a fresh type-variable:
> CAP#1 extends Object from capture of ?
> {noformat}
> This does not affect applications from using Guava 21-22 but does impact our
> compatibility testing. Note that you need to set {{maven.compile.source}} to
> 1.8 to test Guava 21+.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1491) Jclouds uses a deprecated version of Guava to support Azure storage.
[
https://issues.apache.org/jira/browse/JCLOUDS-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124471#comment-17124471
]
ASF subversion and git services commented on JCLOUDS-1491:
--
Commit 20b1394f36dd9e522f2173b344f85a04988ae720 in jclouds's branch
refs/heads/master from Jean-Noël Rouvignac
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=20b1394 ]
JCLOUDS-1491 Jclouds uses a deprecated version of Guava to support Azure storage
DnsNameValidator.java uses a deprecated guava APIs in code that is used
to support Azure cloud storage. When forcing the use of more recent guava
versions, the code fails with NoSuchFieldError.
However, CharMatcher.JAVA_LETTER_OR_DIGIT has been removed in guava 26.0,
and CharMatcher.javaLetterOrDigit() should be used instead since guava
19.0. Note that CharMatcher.javaLetterOrDigit() was immediately
deprecated in Guava 26.0, and java.lang.Character.isLetterOrDigit(int)
should be used instead.
This commit replaces the use of this deprecated API by
java.lang.Character.isLetterOrDigit(int).
It is no worse than the previous code.
(If I understand correctly, updating the guava version is a challenge due to
dependencies on Apache Karaf anyway)
> Jclouds uses a deprecated version of Guava to support Azure storage.
>
>
> Key: JCLOUDS-1491
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1491
> Project: jclouds
> Issue Type: Improvement
>Reporter: Biswa Ranjan Ray
>Assignee: Daniel Estevez
>Priority: Major
> Attachments: jclouds_issue.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi,
> We are facing an issue while using jclouds library along with Guava to
> support Azure storage.
> *Issue:*
> We are using Jclouds 2.1.2 and Guava 27.0.1-jre in our application to work
> with objectstore service offered by several cloud providers. These libraries
> works seamlessly for AWS S3 and GCS. But in case of azure we get an
> exception. Please see the attachment for stack trace.
> *Analysis:*
> We found that the issue is there with the below code in DnsValidator class at
> line 53:
> {code:java}
> if (CharMatcher.JAVA_LETTER_OR_DIGIT.indexIn(name) != 0)
> {code}
> The above static field is deprecated in Guava 27.0.1-jre. But apparently
> jclouds library still refers to a deprecated version of Guava as mentioned in
> the jclouds doc:
> {quote}Setup your project to include 'guava'. Include following dependency to
> jclouds Installation. Update the version mentioned in dependency below to the
> latest available version. com.google.guava guava 16.0
> {quote}
> If not the latest at least we would like to use the recent version of Guava.
> But Guava 16.0 is really old and deprecated as well. Any thoughts are
> appreciated.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1547) Google InputStream blob upload ignores MD5
[
https://issues.apache.org/jira/browse/JCLOUDS-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120454#comment-17120454
]
ASF subversion and git services commented on JCLOUDS-1547:
--
Commit 6e6f8ebf779d8edc5cedec687558637d8212ab18 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=6e6f8eb ]
JCLOUDS-912: JCLOUDS-1547: GCS InputStream single-part upload
Previously this provider worked around a RestAnnotationProcessor quirk
by using multi-part uploads for InputStream payloads. Instead work
around the quirk another way which allows a single-part upload. This
allows inclusion of the Content-MD5 header during object creation.
Backfill tests with both ByteSource and InputStream inputs.
> Google InputStream blob upload ignores MD5
> --
>
> Key: JCLOUDS-1547
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1547
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.0, 2.2.1
>Reporter: Alexander Chernavin
>Assignee: Andrew Gaul
>Priority: Major
> Labels: google-cloud-storage, md5
>
> According to [GCS blob upload
> documentation|[https://cloud.google.com/storage/docs/xml-api/put-object-upload]],
> when Content-MD5 header is provided, Google uses it to verify data integrity
> of an uploaded blob. This feature is crucial for us. We have a file upload
> functionality that takes an input stream and uploads it to a cloud via
> JClouds. We want to be sure that file integrity is enforced.
>
> JClouds blob builder allows to specify content MD5, but this value is ignored
> with InputStream payload, it's simply is not propagated into Content-MD5
> header.
> Here is the code snippet to reproduce the issue:
> {code:java}
> BlobStoreContext context = ContextBuilder.newBuilder("google-cloud-storage")
> .credentials(clientEmail, privateKey)
> .buildView(BlobStoreContext.class);
> // generate MD5 hash for some bogus content
> MessageDigest md5 = MessageDigest.getInstance("MD5");
> md5.update("bogus".getBytes());
> InputStream inputStream = new ByteArrayInputStream("hi".getBytes());
> BlobStore blobStore = context.getBlobStore();
> blobStore.putBlob(myContainer,
> blobStore.blobBuilder("test.txt")
> .payload(inputStream)
> .contentLength(2)
> .contentType("text/plain")
> .contentMD5(HashCode.fromBytes(md5.digest()))
> .build()); {code}
> putBlob should have failed, because payload is "hi", but MD5 is calculated
> for "bogus" string.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-912) GCS uploads with InputStream payloads are not working
[
https://issues.apache.org/jira/browse/JCLOUDS-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17120453#comment-17120453
]
ASF subversion and git services commented on JCLOUDS-912:
-
Commit 6e6f8ebf779d8edc5cedec687558637d8212ab18 in jclouds's branch
refs/heads/master from Andrew Gaul
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=6e6f8eb ]
JCLOUDS-912: JCLOUDS-1547: GCS InputStream single-part upload
Previously this provider worked around a RestAnnotationProcessor quirk
by using multi-part uploads for InputStream payloads. Instead work
around the quirk another way which allows a single-part upload. This
allows inclusion of the Content-MD5 header during object creation.
Backfill tests with both ByteSource and InputStream inputs.
> 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
>Assignee: Andrew Gaul
>Priority: Major
> Labels: google-cloud-storage
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
>
[jira] [Commented] (JCLOUDS-1546) Google Cloud Storage archive tier
[ https://issues.apache.org/jira/browse/JCLOUDS-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17103080#comment-17103080 ] ASF subversion and git services commented on JCLOUDS-1546: -- Commit 08a16c95fbd115f5afed52898e91bacd013e9cde in jclouds's branch refs/heads/master from Andrew Gaul [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=08a16c9 ] JCLOUDS-1546: Support GCS Archive storage class Also change portable abstraction mapping for Tier.ARCHIVE. > Google Cloud Storage archive tier > - > > Key: JCLOUDS-1546 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1546 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.2.1 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Minor > Labels: google-cloud-storage > Time Spent: 10m > Remaining Estimate: 0h > > This tier is colder than Coldline and similar to Amazon Glacier: > > https://cloud.google.com/blog/products/storage-data-transfer/archive-storage-class-for-coldest-data-now-available -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1543) list() results are not in order when using withDetails
[
https://issues.apache.org/jira/browse/JCLOUDS-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089450#comment-17089450
]
ASF subversion and git services commented on JCLOUDS-1543:
--
Commit d220b245d727036f9134e9ba5e1c51dcc31f959e in jclouds's branch
refs/heads/master from roded
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=d220b24 ]
JCLOUDS-1543: remove unused imports from FetchBlobMetadataTest.java (#70)
Co-authored-by: Roded Bahat
> list() results are not in order when using withDetails
> --
>
> Key: JCLOUDS-1543
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1543
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.0
>Reporter: Roded Bahat
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.3.0, 2.2.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When listing blobs using the withDetails ListContainerOption, the returned
> page set's blobs do not return in the original order (as without the
> withDetails option). I suspect that FetchBlobMetadata should try a bit harder
> to keep to page set as it was received.
> {code:java}
> @Test
> public void withDetailsOrdering() {
> BlobStoreContext blobStoreContext = ContextBuilder.newBuilder("s3")
> .endpoint("...")
> .credentials("...", "...")
> .buildView(BlobStoreContext.class);
> BlobStore blobStore = blobStoreContext.getBlobStore();
> String container = "roded-data";
> String blobNamePrefix = "test/blob-";
> for (int blobIndex = 0; blobIndex < 100; blobIndex++) {
> Blob newBlob = blobStore.blobBuilder(blobNamePrefix +
> blobIndex).payload("").build();
> blobStore.putBlob(container, newBlob);
> }
> final PageSet withOutDetails =
> blobStore.list(container,
> ListContainerOptions.Builder.prefix(blobNamePrefix));
> final PageSet withDetails = blobStore
> .list(container,
> ListContainerOptions.Builder.prefix(blobNamePrefix).withDetails());
>
> assertTrue(Ordering.from(Comparator.comparing(StorageMetadata::getName)).isOrdered(withOutDetails));
> // Fails.
>
> assertTrue(Ordering.from(Comparator.comparing(StorageMetadata::getName)).isOrdered(withDetails));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1543) list() results are not in order when using withDetails
[
https://issues.apache.org/jira/browse/JCLOUDS-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089413#comment-17089413
]
ASF subversion and git services commented on JCLOUDS-1543:
--
Commit 76f9a5324724acb97407b93ae289166ca506a67e in jclouds's branch
refs/heads/2.2.x from roded
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=76f9a53 ]
JCLOUDS-1543: remove unused imports from FetchBlobMetadataTest.java (#70)
Co-authored-by: Roded Bahat
> list() results are not in order when using withDetails
> --
>
> Key: JCLOUDS-1543
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1543
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.0
>Reporter: Roded Bahat
>Assignee: Andrew Gaul
>Priority: Major
> Fix For: 2.3.0, 2.2.1
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When listing blobs using the withDetails ListContainerOption, the returned
> page set's blobs do not return in the original order (as without the
> withDetails option). I suspect that FetchBlobMetadata should try a bit harder
> to keep to page set as it was received.
> {code:java}
> @Test
> public void withDetailsOrdering() {
> BlobStoreContext blobStoreContext = ContextBuilder.newBuilder("s3")
> .endpoint("...")
> .credentials("...", "...")
> .buildView(BlobStoreContext.class);
> BlobStore blobStore = blobStoreContext.getBlobStore();
> String container = "roded-data";
> String blobNamePrefix = "test/blob-";
> for (int blobIndex = 0; blobIndex < 100; blobIndex++) {
> Blob newBlob = blobStore.blobBuilder(blobNamePrefix +
> blobIndex).payload("").build();
> blobStore.putBlob(container, newBlob);
> }
> final PageSet withOutDetails =
> blobStore.list(container,
> ListContainerOptions.Builder.prefix(blobNamePrefix));
> final PageSet withDetails = blobStore
> .list(container,
> ListContainerOptions.Builder.prefix(blobNamePrefix).withDetails());
>
> assertTrue(Ordering.from(Comparator.comparing(StorageMetadata::getName)).isOrdered(withOutDetails));
> // Fails.
>
> assertTrue(Ordering.from(Comparator.comparing(StorageMetadata::getName)).isOrdered(withDetails));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1541) Add Middle East (Bahrain) region to the AWS EC2 and S3 providers list
[ https://issues.apache.org/jira/browse/JCLOUDS-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075002#comment-17075002 ] ASF subversion and git services commented on JCLOUDS-1541: -- Commit f8768003708d78fcb599373523599f2bed63cf27 in jclouds's branch refs/heads/2.2.x from ikky888 [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=f876800 ] JCLOUDS-1541: Add Middle East (Bahrain) region to the AWS EC2 and S3 providers list > Add Middle East (Bahrain) region to the AWS EC2 and S3 providers list > - > > Key: JCLOUDS-1541 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1541 > Project: jclouds > Issue Type: Improvement >Reporter: Ikky Ma >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > As titled > Source: [https://docs.aws.amazon.com/general/latest/gr/s3.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1541) Add Middle East (Bahrain) region to the AWS EC2 and S3 providers list
[ https://issues.apache.org/jira/browse/JCLOUDS-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17075001#comment-17075001 ] ASF subversion and git services commented on JCLOUDS-1541: -- Commit 69ca45720d297d4041b8086c069ca24dc56ed564 in jclouds's branch refs/heads/master from ikky888 [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=69ca457 ] JCLOUDS-1541: Add Middle East (Bahrain) region to the AWS EC2 and S3 providers list > Add Middle East (Bahrain) region to the AWS EC2 and S3 providers list > - > > Key: JCLOUDS-1541 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1541 > Project: jclouds > Issue Type: Improvement >Reporter: Ikky Ma >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > As titled > Source: [https://docs.aws.amazon.com/general/latest/gr/s3.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1540) Update Snakeyaml
[ https://issues.apache.org/jira/browse/JCLOUDS-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050009#comment-17050009 ] ASF subversion and git services commented on JCLOUDS-1540: -- Commit eeb5d73a292172aa61ed51e59decc51d46b91676 in jclouds's branch refs/heads/2.2.x from Colm O hEigeartaigh [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=eeb5d73 ] JCLOUDS-1540 - Update Snakeyaml > Update Snakeyaml > > > Key: JCLOUDS-1540 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1540 > Project: jclouds > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Major > Fix For: 2.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This task is to update Snakeyaml - the latest versions contains some > protections against denial of service attacks by default. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1540) Update Snakeyaml
[ https://issues.apache.org/jira/browse/JCLOUDS-1540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050005#comment-17050005 ] ASF subversion and git services commented on JCLOUDS-1540: -- Commit 99ef891e7618dba8982603ab25e0779a71ea85ef in jclouds's branch refs/heads/master from Colm O hEigeartaigh [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=99ef891 ] JCLOUDS-1540 - Update Snakeyaml > Update Snakeyaml > > > Key: JCLOUDS-1540 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1540 > Project: jclouds > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Major > Fix For: 2.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This task is to update Snakeyaml - the latest versions contains some > protections against denial of service attacks by default. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1533) Using Azure SAS Token unable to upload the file specific folder in the container
[
https://issues.apache.org/jira/browse/JCLOUDS-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17038405#comment-17038405
]
ASF subversion and git services commented on JCLOUDS-1533:
--
Commit 7b5db157783d6e41706e18f17b6b48b141c171ab in jclouds's branch
refs/heads/2.2.x from majaseremet
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=7b5db15 ]
JCLOUDS-1533 - Fix upload with SAS token when blob name contains slash (#61)
> Using Azure SAS Token unable to upload the file specific folder in the
> container
>
>
> Key: JCLOUDS-1533
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1533
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.0
>Reporter: Manju
>Priority: Major
> Labels: azureblob
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
>
> *Jcloud version - 2.2.0*
>
> {code:java}
> Using Azure key and secret key - Working fine. (Able to upload the files, It
> will create test1 folder mycontainer and uploads test-data.log file)
> ===
> it should "Upload a file" in {
> val azureKey = AppConf.getStorageKey("azure")
> val azureToken = AppConf.getStorageSecret("azure")import
> org.jclouds.ContextBuilder
> import org.jclouds.blobstore.BlobStoreContext
> val context =
> ContextBuilder.newBuilder("azureblob").credentials(azureKey,
> azureToken).buildView(classOf[BlobStoreContext])var blobStore =
> context.getBlobStore()
> blobStore.createContainerInLocation(null, "mycontainer")
> val fileObj = new File("src/test/resources/test-data.log")
> val payload = Files.asByteSource(fileObj)
> val blob =
> blobStore.blobBuilder("test1/test-data.log").payload(payload).contentLength(payload.size()).build()
> blobStore.putBlob("mycontainer", blob, new PutOptions().multipart())
> context.close()
> }
> {code}
> {code:java}
> Using AZURE SAS Token - It Doesn't work - Unable to upload the file
>
> it should "Upload a file" in {val sasToken = AppConf.getSSAToken("azure")
> val azureKey = AppConf.getStorageKey("azure")
>import org.jclouds.ContextBuilder
> import org.jclouds.blobstore.BlobStoreContext
> val context =
> ContextBuilder.newBuilder("azureblob").credentials(azureKey,
> sasToken).buildView(classOf[BlobStoreContext])var blobStore =
> context.getBlobStore()
> blobStore.createContainerInLocation(null, "mycontainer")
> val fileObj = new File("src/test/resources/test-data.log")
> val payload = Files.asByteSource(fileObj)
> val blob =
> blobStore.blobBuilder("test1/test-data.log").payload(payload).contentLength(payload.size()).build()
> blobStore.putBlob("mycontainer", blob, new PutOptions().multipart())
> context.close()}
> {code}
> *Error: When We use SAS Token with the above code to upload the files into
> (mycontainer/test1/test-data.log)*
>
> {code:java}
> org.jclouds.azure.storage.AzureStorageResponseException: command
> [method=org.jclouds.azureblob.AzureBlobClient.public abstract void
> org.jclouds.azureblob.AzureBlobClient.putBlock(java.lang.String,java.lang.String,java.lang.String,org.jclouds.io.Payload)[mycontainer,
> test1/test-data.log, AQ==, [content=true,
> contentMetadata=[cacheControl=null, contentDisposition=null,
> contentEncoding=null, contentLanguage=null, contentLength=7986,
> contentMD5=null, contentType=application/unknown, expires=null],
> written=false, isSensitive=false]], request=PUT
> https://test.blob.core.windows.net/mycontainer/test1/test-data.log?comp=block=AQ%3D%3D
> HTTP/1.1] failed with code 400, error:
> AzureError{requestId='c13bc6b2-f01e-0020-5acd-b4114e00',
> code='InvalidQueryParameterValue', message='Value for one of the query
> parameters specified in the request URI is invalid.
> RequestId:c13bc6b2-f01e-0020-5acd-b4114e00
> Time:2019-12-17T11:31:17.8460459Z', context='{QueryParameterValue=block,
> QueryParameterName=comp, Reason=}'}
> com.google.common.util.concurrent.UncheckedExecutionException:
> org.jclouds.azure.storage.AzureStorageResponseException: command
> [method=org.jclouds.azureblob.AzureBlobClient.public abstract void
> org.jclouds.azureblob.AzureBlobClient.putBlock(java.lang.String,java.lang.String,java.lang.String,org.jclouds.io.Payload)[mycontainer,
> test1/test-data.log, AQ==, [content=true,
> contentMetadata=[cacheControl=null, contentDisposition=null,
> contentEncoding=null, contentLanguage=null, contentLength=7986,
> contentMD5=null, contentType=application/unknown, expires=null],
> written=false, isSensitive=false]], request=PUT
>
[jira] [Commented] (JCLOUDS-1533) Using Azure SAS Token unable to upload the file specific folder in the container
[
https://issues.apache.org/jira/browse/JCLOUDS-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17038399#comment-17038399
]
ASF subversion and git services commented on JCLOUDS-1533:
--
Commit ca5190636a5fc1ffe48d0d6b8087ad160c0b7d80 in jclouds's branch
refs/heads/master from majaseremet
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=ca51906 ]
JCLOUDS-1533 - Fix upload with SAS token when blob name contains slash (#61)
> Using Azure SAS Token unable to upload the file specific folder in the
> container
>
>
> Key: JCLOUDS-1533
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1533
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-blobstore
>Affects Versions: 2.2.0
>Reporter: Manju
>Priority: Major
> Labels: azureblob
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> *Jcloud version - 2.2.0*
>
> {code:java}
> Using Azure key and secret key - Working fine. (Able to upload the files, It
> will create test1 folder mycontainer and uploads test-data.log file)
> ===
> it should "Upload a file" in {
> val azureKey = AppConf.getStorageKey("azure")
> val azureToken = AppConf.getStorageSecret("azure")import
> org.jclouds.ContextBuilder
> import org.jclouds.blobstore.BlobStoreContext
> val context =
> ContextBuilder.newBuilder("azureblob").credentials(azureKey,
> azureToken).buildView(classOf[BlobStoreContext])var blobStore =
> context.getBlobStore()
> blobStore.createContainerInLocation(null, "mycontainer")
> val fileObj = new File("src/test/resources/test-data.log")
> val payload = Files.asByteSource(fileObj)
> val blob =
> blobStore.blobBuilder("test1/test-data.log").payload(payload).contentLength(payload.size()).build()
> blobStore.putBlob("mycontainer", blob, new PutOptions().multipart())
> context.close()
> }
> {code}
> {code:java}
> Using AZURE SAS Token - It Doesn't work - Unable to upload the file
>
> it should "Upload a file" in {val sasToken = AppConf.getSSAToken("azure")
> val azureKey = AppConf.getStorageKey("azure")
>import org.jclouds.ContextBuilder
> import org.jclouds.blobstore.BlobStoreContext
> val context =
> ContextBuilder.newBuilder("azureblob").credentials(azureKey,
> sasToken).buildView(classOf[BlobStoreContext])var blobStore =
> context.getBlobStore()
> blobStore.createContainerInLocation(null, "mycontainer")
> val fileObj = new File("src/test/resources/test-data.log")
> val payload = Files.asByteSource(fileObj)
> val blob =
> blobStore.blobBuilder("test1/test-data.log").payload(payload).contentLength(payload.size()).build()
> blobStore.putBlob("mycontainer", blob, new PutOptions().multipart())
> context.close()}
> {code}
> *Error: When We use SAS Token with the above code to upload the files into
> (mycontainer/test1/test-data.log)*
>
> {code:java}
> org.jclouds.azure.storage.AzureStorageResponseException: command
> [method=org.jclouds.azureblob.AzureBlobClient.public abstract void
> org.jclouds.azureblob.AzureBlobClient.putBlock(java.lang.String,java.lang.String,java.lang.String,org.jclouds.io.Payload)[mycontainer,
> test1/test-data.log, AQ==, [content=true,
> contentMetadata=[cacheControl=null, contentDisposition=null,
> contentEncoding=null, contentLanguage=null, contentLength=7986,
> contentMD5=null, contentType=application/unknown, expires=null],
> written=false, isSensitive=false]], request=PUT
> https://test.blob.core.windows.net/mycontainer/test1/test-data.log?comp=block=AQ%3D%3D
> HTTP/1.1] failed with code 400, error:
> AzureError{requestId='c13bc6b2-f01e-0020-5acd-b4114e00',
> code='InvalidQueryParameterValue', message='Value for one of the query
> parameters specified in the request URI is invalid.
> RequestId:c13bc6b2-f01e-0020-5acd-b4114e00
> Time:2019-12-17T11:31:17.8460459Z', context='{QueryParameterValue=block,
> QueryParameterName=comp, Reason=}'}
> com.google.common.util.concurrent.UncheckedExecutionException:
> org.jclouds.azure.storage.AzureStorageResponseException: command
> [method=org.jclouds.azureblob.AzureBlobClient.public abstract void
> org.jclouds.azureblob.AzureBlobClient.putBlock(java.lang.String,java.lang.String,java.lang.String,org.jclouds.io.Payload)[mycontainer,
> test1/test-data.log, AQ==, [content=true,
> contentMetadata=[cacheControl=null, contentDisposition=null,
> contentEncoding=null, contentLanguage=null, contentLength=7986,
> contentMD5=null, contentType=application/unknown, expires=null],
> written=false, isSensitive=false]], request=PUT
>
[jira] [Commented] (JCLOUDS-1538) Expires header value is incorrectly formatted in S3 upsert requests
[
https://issues.apache.org/jira/browse/JCLOUDS-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022983#comment-17022983
]
ASF subversion and git services commented on JCLOUDS-1538:
--
Commit 8949bc10d3e5f8f485d142931e7dda3a8a0afc51 in jclouds's branch
refs/heads/2.2.x from Ian Springer
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=8949bc1 ]
JCLOUDS-1538: fix typo in rfc1123SimpleDateFormat (#60)
> Expires header value is incorrectly formatted in S3 upsert requests
> ---
>
> Key: JCLOUDS-1538
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1538
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core
>Affects Versions: 2.1.0, 2.2.0, 2.1.1, 2.1.2, 2.1.3
>Reporter: Ian Springer
>Priority: Major
> Labels: s3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Expires header value has 5, rather than 4, digits for the year portion of
> the date, e.g.:
>
> {code:java}
> Expires: Wed, 22 Jan 02020 22:19:26 +
> {code}
>
> DefaultContentMetadataCodec contains:
>
> {code:java}
> httpExpiresDateCodec = dateCodecs.rfc1123();
> {code}
>
> and SimpleDateFormatDateService, where the RFC1123 codec is implemented,
> contains:
>
> {code:java}
> private static final SimpleDateFormat rfc1123SimpleDateFormat = new
> SimpleDateFormat("EEE, dd MMM y HH:mm:ss Z", Locale.US);
> {code}
>
> Note, it contains 'y', rather than ''.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1538) Expires header value is incorrectly formatted in S3 upsert requests
[
https://issues.apache.org/jira/browse/JCLOUDS-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17022982#comment-17022982
]
ASF subversion and git services commented on JCLOUDS-1538:
--
Commit 3db2939885d222420712612a25c5c7c896953151 in jclouds's branch
refs/heads/master from Ian Springer
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=3db2939 ]
JCLOUDS-1538: fix typo in rfc1123SimpleDateFormat (#60)
> Expires header value is incorrectly formatted in S3 upsert requests
> ---
>
> Key: JCLOUDS-1538
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1538
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core
>Affects Versions: 2.1.0, 2.2.0, 2.1.1, 2.1.2, 2.1.3
>Reporter: Ian Springer
>Priority: Major
> Labels: s3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The Expires header value has 5, rather than 4, digits for the year portion of
> the date, e.g.:
>
> {code:java}
> Expires: Wed, 22 Jan 02020 22:19:26 +
> {code}
>
> DefaultContentMetadataCodec contains:
>
> {code:java}
> httpExpiresDateCodec = dateCodecs.rfc1123();
> {code}
>
> and SimpleDateFormatDateService, where the RFC1123 codec is implemented,
> contains:
>
> {code:java}
> private static final SimpleDateFormat rfc1123SimpleDateFormat = new
> SimpleDateFormat("EEE, dd MMM y HH:mm:ss Z", Locale.US);
> {code}
>
> Note, it contains 'y', rather than ''.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1532) Update SSHJ + JSCH
[ https://issues.apache.org/jira/browse/JCLOUDS-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987049#comment-16987049 ] ASF subversion and git services commented on JCLOUDS-1532: -- Commit b96158e6edaf173b15f047c00f1d6274c9dabe31 in jclouds's branch refs/heads/master from Colm O hEigeartaigh [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=b96158e ] JCLOUDS-1532 - Update SSHJ + JSCH (#57) > Update SSHJ + JSCH > -- > > Key: JCLOUDS-1532 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1532 > Project: jclouds > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Major > Fix For: 2.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We should update SSHJ + JSCH. The current version of SSHJ pulls in an old > version of BouncyCastle, and JSCH has a CVE associated with it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1529) NullPointerException in org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE
[ https://issues.apache.org/jira/browse/JCLOUDS-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984270#comment-16984270 ] ASF subversion and git services commented on JCLOUDS-1529: -- Commit f8a7f7741b0ccd5d5e02f25f6c3e19c7a9cc1810 in jclouds's branch refs/heads/2.2.x from Markus Alexander Kuppe [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=f8a7f77 ] JCLOUDS-1529: Do not export org.jclouds.json.gson.internal (#56) Do not export packages matching org.jclouds.json.gson.internal* because it causes a use constraint violation with OSGi between jclouds-core and jclouds-gson. https://issues.apache.org/jira/browse/JCLOUDS-1529 > NullPointerException in > org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE > > > Key: JCLOUDS-1529 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1529 > Project: jclouds > Issue Type: Bug > Components: jclouds-core >Affects Versions: 2.2.0 >Reporter: Markus Kuppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Trying to launch a compute instance with jclouds 2.2.0 (client code works > with 2.1.1), BaseComputeServiceContextModule throws a NullPointerException > because org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE is > null. > This happens when com.google.gson 2.8.5 when is deployed next to > jclouds-core. When I try to deploy jclouds-gson, it results in a use > constraint violation for package org.jclouds.json.gson.internal.bind.util > between jclouds-core and jclouds-gson. > > Please advise. > — > > !ENTRY org.eclipse.core.jobs 4 2 2019-11-26 20:03:50.967 > !MESSAGE An internal error occurred during: "PacketNet". > !STACK 0 > com.google.inject.CreationException: Guice creation errors: > 1) Error in custom provider, java.lang.NullPointerException > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > while locating java.util.Map java.util.Map> > 1 error > at > com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:435) > at > com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:183) > at > com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109) > at com.google.inject.Guice.createInjector(Guice.java:95) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:405) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:328) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:615) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:595) > at > org.lamport.tla.toolbox.jcloud.CloudDistributedTLCJob.run(CloudDistributedTLCJob.java:192) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) > Caused by: java.lang.NullPointerException > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:319) > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:287) > at com.google.gson.Gson.fromJson(Gson.java:927) > at com.google.gson.Gson.fromJson(Gson.java:892) > at com.google.gson.Gson.fromJson(Gson.java:841) > at org.jclouds.json.internal.GsonWrapper.fromJson(GsonWrapper.java:44) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:104) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) > at com.google.inject.Scopes$1$1.get(Scopes.java:65) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at >
[jira] [Commented] (JCLOUDS-1529) NullPointerException in org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE
[ https://issues.apache.org/jira/browse/JCLOUDS-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984269#comment-16984269 ] ASF subversion and git services commented on JCLOUDS-1529: -- Commit f8a7f7741b0ccd5d5e02f25f6c3e19c7a9cc1810 in jclouds's branch refs/heads/2.2.x from Markus Alexander Kuppe [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=f8a7f77 ] JCLOUDS-1529: Do not export org.jclouds.json.gson.internal (#56) Do not export packages matching org.jclouds.json.gson.internal* because it causes a use constraint violation with OSGi between jclouds-core and jclouds-gson. https://issues.apache.org/jira/browse/JCLOUDS-1529 > NullPointerException in > org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE > > > Key: JCLOUDS-1529 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1529 > Project: jclouds > Issue Type: Bug > Components: jclouds-core >Affects Versions: 2.2.0 >Reporter: Markus Kuppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Trying to launch a compute instance with jclouds 2.2.0 (client code works > with 2.1.1), BaseComputeServiceContextModule throws a NullPointerException > because org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE is > null. > This happens when com.google.gson 2.8.5 when is deployed next to > jclouds-core. When I try to deploy jclouds-gson, it results in a use > constraint violation for package org.jclouds.json.gson.internal.bind.util > between jclouds-core and jclouds-gson. > > Please advise. > — > > !ENTRY org.eclipse.core.jobs 4 2 2019-11-26 20:03:50.967 > !MESSAGE An internal error occurred during: "PacketNet". > !STACK 0 > com.google.inject.CreationException: Guice creation errors: > 1) Error in custom provider, java.lang.NullPointerException > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > while locating java.util.Map java.util.Map> > 1 error > at > com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:435) > at > com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:183) > at > com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109) > at com.google.inject.Guice.createInjector(Guice.java:95) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:405) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:328) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:615) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:595) > at > org.lamport.tla.toolbox.jcloud.CloudDistributedTLCJob.run(CloudDistributedTLCJob.java:192) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) > Caused by: java.lang.NullPointerException > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:319) > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:287) > at com.google.gson.Gson.fromJson(Gson.java:927) > at com.google.gson.Gson.fromJson(Gson.java:892) > at com.google.gson.Gson.fromJson(Gson.java:841) > at org.jclouds.json.internal.GsonWrapper.fromJson(GsonWrapper.java:44) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:104) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) > at com.google.inject.Scopes$1$1.get(Scopes.java:65) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at >
[jira] [Commented] (JCLOUDS-1529) NullPointerException in org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE
[ https://issues.apache.org/jira/browse/JCLOUDS-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984265#comment-16984265 ] ASF subversion and git services commented on JCLOUDS-1529: -- Commit 11d05ac9bf3f5a97076f2c745b88ab86661b31fd in jclouds's branch refs/heads/master from Markus Alexander Kuppe [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=11d05ac ] JCLOUDS-1529: Do not export org.jclouds.json.gson.internal (#56) Do not export packages matching org.jclouds.json.gson.internal* because it causes a use constraint violation with OSGi between jclouds-core and jclouds-gson. https://issues.apache.org/jira/browse/JCLOUDS-1529 > NullPointerException in > org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE > > > Key: JCLOUDS-1529 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1529 > Project: jclouds > Issue Type: Bug > Components: jclouds-core >Affects Versions: 2.2.0 >Reporter: Markus Kuppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Trying to launch a compute instance with jclouds 2.2.0 (client code works > with 2.1.1), BaseComputeServiceContextModule throws a NullPointerException > because org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE is > null. > This happens when com.google.gson 2.8.5 when is deployed next to > jclouds-core. When I try to deploy jclouds-gson, it results in a use > constraint violation for package org.jclouds.json.gson.internal.bind.util > between jclouds-core and jclouds-gson. > > Please advise. > — > > !ENTRY org.eclipse.core.jobs 4 2 2019-11-26 20:03:50.967 > !MESSAGE An internal error occurred during: "PacketNet". > !STACK 0 > com.google.inject.CreationException: Guice creation errors: > 1) Error in custom provider, java.lang.NullPointerException > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > while locating java.util.Map java.util.Map> > 1 error > at > com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:435) > at > com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:183) > at > com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109) > at com.google.inject.Guice.createInjector(Guice.java:95) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:405) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:328) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:615) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:595) > at > org.lamport.tla.toolbox.jcloud.CloudDistributedTLCJob.run(CloudDistributedTLCJob.java:192) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) > Caused by: java.lang.NullPointerException > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:319) > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:287) > at com.google.gson.Gson.fromJson(Gson.java:927) > at com.google.gson.Gson.fromJson(Gson.java:892) > at com.google.gson.Gson.fromJson(Gson.java:841) > at org.jclouds.json.internal.GsonWrapper.fromJson(GsonWrapper.java:44) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:104) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) > at com.google.inject.Scopes$1$1.get(Scopes.java:65) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at >
[jira] [Commented] (JCLOUDS-1529) NullPointerException in org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE
[ https://issues.apache.org/jira/browse/JCLOUDS-1529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984266#comment-16984266 ] ASF subversion and git services commented on JCLOUDS-1529: -- Commit 11d05ac9bf3f5a97076f2c745b88ab86661b31fd in jclouds's branch refs/heads/master from Markus Alexander Kuppe [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=11d05ac ] JCLOUDS-1529: Do not export org.jclouds.json.gson.internal (#56) Do not export packages matching org.jclouds.json.gson.internal* because it causes a use constraint violation with OSGi between jclouds-core and jclouds-gson. https://issues.apache.org/jira/browse/JCLOUDS-1529 > NullPointerException in > org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE > > > Key: JCLOUDS-1529 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1529 > Project: jclouds > Issue Type: Bug > Components: jclouds-core >Affects Versions: 2.2.0 >Reporter: Markus Kuppe >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Trying to launch a compute instance with jclouds 2.2.0 (client code works > with 2.1.1), BaseComputeServiceContextModule throws a NullPointerException > because org.jclouds.json.gson.internal.JsonReaderInternalAccess.INSTANCE is > null. > This happens when com.google.gson 2.8.5 when is deployed next to > jclouds-core. When I try to deploy jclouds-gson, it results in a use > constraint violation for package org.jclouds.json.gson.internal.bind.util > between jclouds-core and jclouds-gson. > > Please advise. > — > > !ENTRY org.eclipse.core.jobs 4 2 2019-11-26 20:03:50.967 > !MESSAGE An internal error occurred during: "PacketNet". > !STACK 0 > com.google.inject.CreationException: Guice creation errors: > 1) Error in custom provider, java.lang.NullPointerException > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > while locating java.util.Map java.util.Map> > 1 error > at > com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:435) > at > com.google.inject.internal.InternalInjectorCreator.injectDynamically(InternalInjectorCreator.java:183) > at > com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:109) > at com.google.inject.Guice.createInjector(Guice.java:95) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:405) > at org.jclouds.ContextBuilder.buildInjector(ContextBuilder.java:328) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:615) > at org.jclouds.ContextBuilder.buildView(ContextBuilder.java:595) > at > org.lamport.tla.toolbox.jcloud.CloudDistributedTLCJob.run(CloudDistributedTLCJob.java:192) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) > Caused by: java.lang.NullPointerException > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:319) > at > org.jclouds.json.internal.NullFilteringTypeAdapterFactories$MapTypeAdapter.read(NullFilteringTypeAdapterFactories.java:287) > at com.google.gson.Gson.fromJson(Gson.java:927) > at com.google.gson.Gson.fromJson(Gson.java:892) > at com.google.gson.Gson.fromJson(Gson.java:841) > at org.jclouds.json.internal.GsonWrapper.fromJson(GsonWrapper.java:44) > at > org.jclouds.compute.config.BaseComputeServiceContextModule.provideOsVersionMap(BaseComputeServiceContextModule.java:172) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.google.inject.internal.ProviderMethod.get(ProviderMethod.java:104) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031) > at > com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) > at com.google.inject.Scopes$1$1.get(Scopes.java:65) > at > com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40) > at >
[jira] [Commented] (JCLOUDS-1528) Use TLS instead of SSL in SSLContext.getInstance
[ https://issues.apache.org/jira/browse/JCLOUDS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16981580#comment-16981580 ] ASF subversion and git services commented on JCLOUDS-1528: -- Commit 3a338da68250ceee071f8c38cffe3660b3c3b6b4 in jclouds's branch refs/heads/master from Colm O hEigeartaigh [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=3a338da ] JCLOUDS-1528 - Use TLS instead of SSL in SSLContext.getInstance (#55) > Use TLS instead of SSL in SSLContext.getInstance > > > Key: JCLOUDS-1528 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1528 > Project: jclouds > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.3.0 > > Time Spent: 20m > Remaining Estimate: 0h > > We should use TLS instead of SSL in SSLContext.getInstance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1525) Update xmlbuilder dependency
[
https://issues.apache.org/jira/browse/JCLOUDS-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975159#comment-16975159
]
ASF subversion and git services commented on JCLOUDS-1525:
--
Commit 5f08ee2f1a3d5986b25f72e5dc102b7cd1fda773 in jclouds's branch
refs/heads/master from Colm O hEigeartaigh
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=5f08ee2 ]
JCLOUDS-1525 - Update xmlbuilder dependency (#52)
> Update xmlbuilder dependency
>
>
> Key: JCLOUDS-1525
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1525
> Project: jclouds
> Issue Type: Improvement
>Reporter: Colm O hEigeartaigh
>Priority: Major
> Fix For: 2.3.0, 2.2.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The xmlbuilder dependency needs to be updated due to a security issue:
> java-xmlbuilder-1.1.jar (pkg:maven/com.jamesmurty.utils/java-xmlbuilder@1.1)
> : CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1526) Update BouncyCastle dependency
[ https://issues.apache.org/jira/browse/JCLOUDS-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975160#comment-16975160 ] ASF subversion and git services commented on JCLOUDS-1526: -- Commit 30830bfa4e41b0647b343892c6c41b0bf797a1ee in jclouds's branch refs/heads/master from Colm O hEigeartaigh [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=30830bf ] JCLOUDS-1526 - Update BouncyCastle dependency (#53) > Update BouncyCastle dependency > -- > > Key: JCLOUDS-1526 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1526 > Project: jclouds > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Major > Fix For: 2.3.0, 2.2.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The BouncyCastle dependency should be updated. The current version used has > numerous CVEs: > bcprov-ext-jdk15on-1.51.jar > (pkg:maven/org.bouncycastle/bcprov-ext-jdk15on@1.51) : CVE-2015-6644, > CVE-2016-1000338, CVE-2016-1000339, CVE-2016-1000340, CVE-2016-1000341, > CVE-2016-1000342, CVE-2016-1000343, CVE-2016-1000344, CVE-2016-1000345, > CVE-2016-1000346, CVE-2016-1000352, CVE-2017-13098, CVE-2018-1000613 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1520) JClouds is not using the JDK's KeepAliveCache when UntrustedSSLContextSupplier is used
[
https://issues.apache.org/jira/browse/JCLOUDS-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952584#comment-16952584
]
ASF subversion and git services commented on JCLOUDS-1520:
--
Commit 6d389b0d8692fd660e77029fde40e5bb363ff6f8 in jclouds's branch
refs/heads/master from roded
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=6d389b0 ]
JCLOUDS-1520: change UntrustedSSLContextSupplier to return the same SSLContext
(#49)
Using the same SSLContext prevents consistent cache misses on the JVM's
KeepAliveCache
when attempting to reuse TLS connections.
> JClouds is not using the JDK's KeepAliveCache when
> UntrustedSSLContextSupplier is used
> --
>
> Key: JCLOUDS-1520
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1520
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-core
>Affects Versions: 2.1.0
>Reporter: Roded Bahat
>Priority: Major
> Attachments: screenshot-1.png
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It seems like the fact that {{UntrustedSSLContextSupplier}} returns a new
> {{SSLContext}} on every {{get()}} call causes a consistent cache miss on the
> JVM's {{sun.net.www.http.KeepAliveCache}} which causes JClouds to not reuse
> existing TLS connections even though it could.
> The cache miss happens at {{sun.net.www.protocol.https.HttpsClient}} line 329
> (openjdk version "1.8.0_222"):
> {noformat}
> /* see if one's already around */
> ret = (HttpsClient) kac.get(url, sf);
> {noformat}
> To reproduce, consider the following main:
> {noformat}
> public static void main(String[] args) {
> Properties overrides = new Properties();
> overrides.setProperty(org.jclouds.Constants.PROPERTY_TRUST_ALL_CERTS,
> "true");
> BlobStoreContext blobStoreContext =
> ContextBuilder.newBuilder("aws-s3")
> .endpoint("https://s3.amazonaws.com;)
> .credentials("...", "...")
> .overrides(overrides)
> .buildView(BlobStoreContext.class);
> BlobStore blobStore = blobStoreContext.getBlobStore();
> blobStore.getBlob("roded-data", "blobname");
> blobStore.getBlob("roded-data", "blobname");
> blobStore.getBlob("roded-data", "blobname");
> blobStoreContext.close();
> System.exit(0);
> }
> {noformat}
> If run using a JUL logging.properties with the following logger set to FINEST:
> {noformat}
> sun.net.www.protocol.http.level=FINEST
> {noformat}
> The following log is produced:
> {noformat}
> 2019-10-10 18:15:19.668 FINE[org.jclouds.rest.internal.InvokeHttpMethod ]
> >> invoking GetBucketLocation
> 2019-10-10 18:15:19.733 FINE
> [org.jclouds.http.internal.JavaUrlHttpCommandExecutorService ] Sending
> request -1721710788: GET https://s3.amazonaws.com/roded-data?location HTTP/1.1
> 2019-10-10 18:15:19.893 FINEST [sun.net.www.protocol.http.HttpURLConnection
> ] Looking for HttpClient for URL https://s3.amazonaws.com/roded-data?location
> and proxy value of DIRECT
> 2019-10-10 18:15:19.893 FINEST [sun.net.www.protocol.http.HttpURLConnection
> ] Creating new HttpsClient with
> url:https://s3.amazonaws.com/roded-data?location and proxy:DIRECT with
> connect timeout:6
> 2019-10-10 18:15:20.837 FINE[sun.net.www.protocol.http.HttpURLConnection
> ] sun.net.www.MessageHeader@537b32ef8 pairs: {GET /roded-data?location
> HTTP/1.1: null}{x-amz-content-sha256:
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855}{X-Amz-Date:
> 20191010T151519Z}{Authorization: AWS4-HMAC-SHA256
> Credential=AKIAJO5RLGWKFW5ASG3A/20191010/us-east-1/s3/aws4_request,
> SignedHeaders=host;x-amz-content-sha256;x-amz-date,
> Signature=896e11ddd9efac465b6ff2506d1688d454a50b3f73ac68d557ad036b1826e591}{User-Agent:
> jclouds/2019.224.2 java/1.8.0_222}{Host: s3.amazonaws.com}{Accept:
> text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive}
> 2019-10-10 18:15:21.169 FINE[sun.net.www.protocol.http.HttpURLConnection
> ] sun.net.www.MessageHeader@6f815e7f7 pairs: {null: HTTP/1.1 200
> OK}{x-amz-id-2:
> 1VVlx4h/fBOFe3n/7IxvpWN0RoVcE2rSpnnxMjvAQ93lJ6tHJAS+3IlXAx++/ZMEblp7kjJT4eQ=}{x-amz-request-id:
> AE0779131201B495}{Date: Thu, 10 Oct 2019 15:15:21 GMT}{Content-Type:
> application/xml}{Transfer-Encoding: chunked}{Server: AmazonS3}
> 2019-10-10 18:15:21.185 FINE
> [org.jclouds.http.internal.JavaUrlHttpCommandExecutorService ] Receiving
> response -1721710788: HTTP/1.1 200 OK
> 2019-10-10 18:15:21.500 FINE[org.jclouds.rest.internal.InvokeHttpMethod ]
> >> invoking GetObject
> 2019-10-10 18:15:21.514 FINE
> [org.jclouds.http.internal.JavaUrlHttpCommandExecutorService ] Sending
> request -1332190413: GET
>
[jira] [Commented] (JCLOUDS-1505) BlobStore.blobMetadata(container, object) returns a StorageMetadata object with empty size when using org.jclouds.http.apachehc.config.ApacheHCHttpCommandExecutorServ
[
https://issues.apache.org/jira/browse/JCLOUDS-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948782#comment-16948782
]
ASF subversion and git services commented on JCLOUDS-1505:
--
Commit 6303d9630840e99ea150e6ad192ed4c8b89b8295 in jclouds's branch
refs/heads/2.1.x from Xavier BOURGOUIN
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=6303d96 ]
Fix null content-length header on HEAD requests
https://issues.apache.org/jira/projects/JCLOUDS/issues/JCLOUDS-1505
> BlobStore.blobMetadata(container, object) returns a StorageMetadata object
> with empty size when using
> org.jclouds.http.apachehc.config.ApacheHCHttpCommandExecutorServiceModule
> ---
>
> Key: JCLOUDS-1505
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1505
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-drivers
>Reporter: Xavier BOURGOUIN
>Priority: Major
> Attachments: jclouds_null_size_reproducer.tar.gz
>
>
> Hello,
>
> When calling *blobStore.blobMetadata(container, objectName).getSize()* with a
> blobStoreContext using ApacheHCHttpCommandExecutorServiceModule, the returned
> BlobMetadata object has a size attribute which is null.
> Issue spotted while using jclouds 2.1.2 over an S3 object store (Scality, but
> seems like it is reproducible with any other S3 provider, and potentially
> others OS providers like GCS, to be confirmed).
> In essence, the minimal reproducer pseudo-code is:
> {code:java}
> BlobStoreContext context = ContextBuilder.newBuilder(provider)
> .credentials(identity, credential)
> .endpoint(endpoint)
> // usage of ApacheHCHttp module
> .modules(ImmutableList. of(new
> ApacheHCHttpCommandExecutorServiceModule(), new SLF4JLoggingModule()))
> .buildView(BlobStoreContext.class);
>
> try {
> BlobStore blobStore = context.getBlobStore();
> // output is: "File size from metadata: null"
> System.out.println("File size from metadata: " +
> blobStore.blobMetadata(DUMMY_CONTAINER, DUMMY_FILE_NAME).getSize());
> } finally {
> context.close();
> }
> {code}
>
> For convenience, I've attached a ready to run reproducer to this ticket,
> here's how to run it:
>
> {code:bash}
> > mkdir reproducer
> > tar xvzf jclouds_null_size_reproducer.tar.gz -C reproducer
> > cd reproducer
> > mvn install
> # note: pre-req from this stage is to have an S3 Object Store available, you
> can use minio one if you have docker (docker run -it -p 9000:9000 -v
> /mnt/data:/data minio/minio server /data)
> # replace with your Object Store endpoint, identity and access key
> > java -jar target/blobstore-basics-jar-with-dependencies.jar s3
> > http://10.66.33.1:9000
> File size from metadata: 8
> File size from metadata (with ApacheHCHttpCommandExecutorServiceModule): null
> {code}
> The reproducer code has jclouds-wire logs enabled (inside log folder) and
> I've also added the log files inside the attached tarball for convenience. We
> see that in the HTTP HEAD response (the 2nd one, which correspond to my
> .blobMetadata() call using ApacheHCHttpCommandExecutorServiceModule), the
> Content-* headers are missing :
> {code:bash}
> >cat log/jclouds-wire.log
> # note: first .blobMetadata() call without
> ApacheHCHttpCommandExecutorServiceModule, the response contains Content-*
> headers
> 2019-07-31 17:30:13,257 DEBUG [jclouds.headers] [main] >> HEAD
> http://10.66.33.1:9000/foo/example_for_empty_size HTTP/1.1
> 2019-07-31 17:30:13,258 DEBUG [jclouds.headers] [main] >> Date: Wed, 31 Jul
> 2019 15:30:13 GMT
> 2019-07-31 17:30:13,258 DEBUG [jclouds.headers] [main] >> Authorization: AWS
> 8A0CESVSLMU5HSSBIOB0:hvzLzlfV+ep7K6Om+tfFss5AuZE=
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << HTTP/1.1 200 OK
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Accept-Ranges: bytes
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Server:
> MinIO/RELEASE.2019-07-24T02-02-23Z
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << ETag:
> "35a41457219c775659b6018fb7f465a1-1"
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << X-Xss-Protection:
> 1; mode=block
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] <<
> Content-Security-Policy: block-all-mixed-content
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Vary: Origin
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Last-Modified: Wed,
> 31 Jul 2019 15:30:13 GMT
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Date: Wed, 31 Jul
> 2019 15:30:13 GMT
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << X-Amz-Request-Id:
> 15B687995977CC49
> 2019-07-31 17:30:13,259
[jira] [Commented] (JCLOUDS-1505) BlobStore.blobMetadata(container, object) returns a StorageMetadata object with empty size when using org.jclouds.http.apachehc.config.ApacheHCHttpCommandExecutorServ
[
https://issues.apache.org/jira/browse/JCLOUDS-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948778#comment-16948778
]
ASF subversion and git services commented on JCLOUDS-1505:
--
Commit c445547ea80a184a328591b40c182a208c6670d5 in jclouds's branch
refs/heads/master from Xavier BOURGOUIN
[ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=c445547 ]
Fix null content-length header on HEAD requests
https://issues.apache.org/jira/projects/JCLOUDS/issues/JCLOUDS-1505
> BlobStore.blobMetadata(container, object) returns a StorageMetadata object
> with empty size when using
> org.jclouds.http.apachehc.config.ApacheHCHttpCommandExecutorServiceModule
> ---
>
> Key: JCLOUDS-1505
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1505
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-drivers
>Reporter: Xavier BOURGOUIN
>Priority: Major
> Attachments: jclouds_null_size_reproducer.tar.gz
>
>
> Hello,
>
> When calling *blobStore.blobMetadata(container, objectName).getSize()* with a
> blobStoreContext using ApacheHCHttpCommandExecutorServiceModule, the returned
> BlobMetadata object has a size attribute which is null.
> Issue spotted while using jclouds 2.1.2 over an S3 object store (Scality, but
> seems like it is reproducible with any other S3 provider, and potentially
> others OS providers like GCS, to be confirmed).
> In essence, the minimal reproducer pseudo-code is:
> {code:java}
> BlobStoreContext context = ContextBuilder.newBuilder(provider)
> .credentials(identity, credential)
> .endpoint(endpoint)
> // usage of ApacheHCHttp module
> .modules(ImmutableList. of(new
> ApacheHCHttpCommandExecutorServiceModule(), new SLF4JLoggingModule()))
> .buildView(BlobStoreContext.class);
>
> try {
> BlobStore blobStore = context.getBlobStore();
> // output is: "File size from metadata: null"
> System.out.println("File size from metadata: " +
> blobStore.blobMetadata(DUMMY_CONTAINER, DUMMY_FILE_NAME).getSize());
> } finally {
> context.close();
> }
> {code}
>
> For convenience, I've attached a ready to run reproducer to this ticket,
> here's how to run it:
>
> {code:bash}
> > mkdir reproducer
> > tar xvzf jclouds_null_size_reproducer.tar.gz -C reproducer
> > cd reproducer
> > mvn install
> # note: pre-req from this stage is to have an S3 Object Store available, you
> can use minio one if you have docker (docker run -it -p 9000:9000 -v
> /mnt/data:/data minio/minio server /data)
> # replace with your Object Store endpoint, identity and access key
> > java -jar target/blobstore-basics-jar-with-dependencies.jar s3
> > http://10.66.33.1:9000
> File size from metadata: 8
> File size from metadata (with ApacheHCHttpCommandExecutorServiceModule): null
> {code}
> The reproducer code has jclouds-wire logs enabled (inside log folder) and
> I've also added the log files inside the attached tarball for convenience. We
> see that in the HTTP HEAD response (the 2nd one, which correspond to my
> .blobMetadata() call using ApacheHCHttpCommandExecutorServiceModule), the
> Content-* headers are missing :
> {code:bash}
> >cat log/jclouds-wire.log
> # note: first .blobMetadata() call without
> ApacheHCHttpCommandExecutorServiceModule, the response contains Content-*
> headers
> 2019-07-31 17:30:13,257 DEBUG [jclouds.headers] [main] >> HEAD
> http://10.66.33.1:9000/foo/example_for_empty_size HTTP/1.1
> 2019-07-31 17:30:13,258 DEBUG [jclouds.headers] [main] >> Date: Wed, 31 Jul
> 2019 15:30:13 GMT
> 2019-07-31 17:30:13,258 DEBUG [jclouds.headers] [main] >> Authorization: AWS
> 8A0CESVSLMU5HSSBIOB0:hvzLzlfV+ep7K6Om+tfFss5AuZE=
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << HTTP/1.1 200 OK
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Accept-Ranges: bytes
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Server:
> MinIO/RELEASE.2019-07-24T02-02-23Z
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << ETag:
> "35a41457219c775659b6018fb7f465a1-1"
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << X-Xss-Protection:
> 1; mode=block
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] <<
> Content-Security-Policy: block-all-mixed-content
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Vary: Origin
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Last-Modified: Wed,
> 31 Jul 2019 15:30:13 GMT
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << Date: Wed, 31 Jul
> 2019 15:30:13 GMT
> 2019-07-31 17:30:13,259 DEBUG [jclouds.headers] [main] << X-Amz-Request-Id:
> 15B687995977CC49
> 2019-07-31
[jira] [Commented] (JCLOUDS-1428) Support for SAS token based Authentication for Azure Blob Storage
[ https://issues.apache.org/jira/browse/JCLOUDS-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943590#comment-16943590 ] ASF subversion and git services commented on JCLOUDS-1428: -- Commit 92ab5a1d1a4317be7f01b21944277d48c067cc67 in jclouds's branch refs/heads/2.1.x from d065488 [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=92ab5a1 ] JCLOUDS-1428 - Support for SAS token based Authentication for Azure Blob Storage - removed sp and se tokens from the check > Support for SAS token based Authentication for Azure Blob Storage > - > > Key: JCLOUDS-1428 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1428 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Reporter: Himanshu Jain >Assignee: Andrew Gaul >Priority: Major > Labels: azureblob > Fix For: 2.2.0, 2.1.3 > > Attachments: azure_stacktrace.txt > > Time Spent: 1.5h > Remaining Estimate: 0h > > Hi, > We have one use case where we want to provide limited access to objects in > our storage accounts. We figured that the best way to do this is by using > SAS token based authentication mechanism to upload/download objects to Azure > Blob Storage - [SAS based > Authentication|https://docs.microsoft.com/en-us/azure/storage/common/storage-dotnet-shared-access-signature-part-1] > We found that JClouds client library provides support for Azure Blob Storage > using account keys which might not fit our use case because of security > reasons. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1512) Use SecureRandom in Sha512Crypt
[ https://issues.apache.org/jira/browse/JCLOUDS-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913452#comment-16913452 ] ASF subversion and git services commented on JCLOUDS-1512: -- Commit ee880e9f4280d943536e1c5c82949bbf1f527fb3 in jclouds's branch refs/heads/2.1.x from Colm O hEigeartaigh [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=ee880e9 ] JCLOUDS-1512 - Use SecureRandom in Sha512Crypt > Use SecureRandom in Sha512Crypt > --- > > Key: JCLOUDS-1512 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1512 > Project: jclouds > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Sha512Crypt uses java.util.Random to generate a random salt which is not > secure. For reference, the Commons Codec Sha512Crypt implementation uses > SecureRandom if a user-specified salt is not supplied: > [https://github.com/apache/commons-codec/blob/30e5768186f73552b5f1634a76cf2c12bf26b5bb/src/main/java/org/apache/commons/codec/digest/Sha2Crypt.java#L138] > [https://github.com/apache/commons-codec/blob/30e5768186f73552b5f1634a76cf2c12bf26b5bb/src/main/java/org/apache/commons/codec/digest/B64.java#L81] > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCLOUDS-1512) Use SecureRandom in Sha512Crypt
[ https://issues.apache.org/jira/browse/JCLOUDS-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16913451#comment-16913451 ] ASF subversion and git services commented on JCLOUDS-1512: -- Commit 7b1efdc30746e68333198c332bbca3f336f68098 in jclouds's branch refs/heads/master from Colm O hEigeartaigh [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=7b1efdc ] JCLOUDS-1512 - Use SecureRandom in Sha512Crypt > Use SecureRandom in Sha512Crypt > --- > > Key: JCLOUDS-1512 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1512 > Project: jclouds > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Sha512Crypt uses java.util.Random to generate a random salt which is not > secure. For reference, the Commons Codec Sha512Crypt implementation uses > SecureRandom if a user-specified salt is not supplied: > [https://github.com/apache/commons-codec/blob/30e5768186f73552b5f1634a76cf2c12bf26b5bb/src/main/java/org/apache/commons/codec/digest/Sha2Crypt.java#L138] > [https://github.com/apache/commons-codec/blob/30e5768186f73552b5f1634a76cf2c12bf26b5bb/src/main/java/org/apache/commons/codec/digest/B64.java#L81] > > -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (JCLOUDS-1509) ParseAWSErrorFromXmlContent uses the default charset
[ https://issues.apache.org/jira/browse/JCLOUDS-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903073#comment-16903073 ] ASF subversion and git services commented on JCLOUDS-1509: -- Commit 95c4443022f9bfaa87952d5ac59befe0b89d755e in jclouds's branch refs/heads/2.1.x from Roded Bahat [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=95c4443 ] JCLOUDS-1509: read AWS response data with the UTF-8 charset explicitly AWS response data is encoded in UTF-8. Creating a String from said data using the JVM's default charset results in incorrect encoding on environments in which the JVM's default charset is not UTF-8. https://issues.apache.org/jira/browse/JCLOUDS-1509 > ParseAWSErrorFromXmlContent uses the default charset > > > Key: JCLOUDS-1509 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1509 > Project: jclouds > Issue Type: Bug >Reporter: Roded Bahat >Priority: Major > > ParseAWSErrorFromXmlContent handleError() creates a String from the data byte > array using the default charset. This breaks on environment in which the > default char set is not UTF-8 causing JClouds to fail refining the AWS > exception. > I suspect that the default AWS response charset is UTF-8: > [https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (JCLOUDS-1509) ParseAWSErrorFromXmlContent uses the default charset
[ https://issues.apache.org/jira/browse/JCLOUDS-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903074#comment-16903074 ] ASF subversion and git services commented on JCLOUDS-1509: -- Commit 95c4443022f9bfaa87952d5ac59befe0b89d755e in jclouds's branch refs/heads/2.1.x from Roded Bahat [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=95c4443 ] JCLOUDS-1509: read AWS response data with the UTF-8 charset explicitly AWS response data is encoded in UTF-8. Creating a String from said data using the JVM's default charset results in incorrect encoding on environments in which the JVM's default charset is not UTF-8. https://issues.apache.org/jira/browse/JCLOUDS-1509 > ParseAWSErrorFromXmlContent uses the default charset > > > Key: JCLOUDS-1509 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1509 > Project: jclouds > Issue Type: Bug >Reporter: Roded Bahat >Priority: Major > > ParseAWSErrorFromXmlContent handleError() creates a String from the data byte > array using the default charset. This breaks on environment in which the > default char set is not UTF-8 causing JClouds to fail refining the AWS > exception. > I suspect that the default AWS response charset is UTF-8: > [https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (JCLOUDS-1509) ParseAWSErrorFromXmlContent uses the default charset
[ https://issues.apache.org/jira/browse/JCLOUDS-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903069#comment-16903069 ] ASF subversion and git services commented on JCLOUDS-1509: -- Commit a248697c0668f8f1c442b04e3833d876b125dc2c in jclouds's branch refs/heads/master from Roded Bahat [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=a248697 ] JCLOUDS-1509: read AWS response data with the UTF-8 charset explicitly AWS response data is encoded in UTF-8. Creating a String from said data using the JVM's default charset results in incorrect encoding on environments in which the JVM's default charset is not UTF-8. https://issues.apache.org/jira/browse/JCLOUDS-1509 > ParseAWSErrorFromXmlContent uses the default charset > > > Key: JCLOUDS-1509 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1509 > Project: jclouds > Issue Type: Bug >Reporter: Roded Bahat >Priority: Major > > ParseAWSErrorFromXmlContent handleError() creates a String from the data byte > array using the default charset. This breaks on environment in which the > default char set is not UTF-8 causing JClouds to fail refining the AWS > exception. > I suspect that the default AWS response charset is UTF-8: > [https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (JCLOUDS-1509) ParseAWSErrorFromXmlContent uses the default charset
[ https://issues.apache.org/jira/browse/JCLOUDS-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903070#comment-16903070 ] ASF subversion and git services commented on JCLOUDS-1509: -- Commit a248697c0668f8f1c442b04e3833d876b125dc2c in jclouds's branch refs/heads/master from Roded Bahat [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=a248697 ] JCLOUDS-1509: read AWS response data with the UTF-8 charset explicitly AWS response data is encoded in UTF-8. Creating a String from said data using the JVM's default charset results in incorrect encoding on environments in which the JVM's default charset is not UTF-8. https://issues.apache.org/jira/browse/JCLOUDS-1509 > ParseAWSErrorFromXmlContent uses the default charset > > > Key: JCLOUDS-1509 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1509 > Project: jclouds > Issue Type: Bug >Reporter: Roded Bahat >Priority: Major > > ParseAWSErrorFromXmlContent handleError() creates a String from the data byte > array using the default charset. This breaks on environment in which the > default char set is not UTF-8 causing JClouds to fail refining the AWS > exception. > I suspect that the default AWS response charset is UTF-8: > [https://docs.aws.amazon.com/AmazonS3/latest/API/ErrorResponses.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (JCLOUDS-1500) Update gson to 2.8.5
[ https://issues.apache.org/jira/browse/JCLOUDS-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16877546#comment-16877546 ] ASF subversion and git services commented on JCLOUDS-1500: -- Commit 51da020d2e4a82c59bb25986db6140c26c406122 in jclouds's branch refs/heads/master from Olaf Flebbe [ https://gitbox.apache.org/repos/asf?p=jclouds.git;h=51da020 ] JCLOUDS-1500: Update gson to 2.8.5 (#29) > Update gson to 2.8.5 > > > Key: JCLOUDS-1500 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1500 > Project: jclouds > Issue Type: Task >Reporter: Olaf Flebbe >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Update gson to a recent version. I took 2.8.5 but I am open to target a > different version instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1166) Remove uses of the 'com.google.gson.internal' package
[
https://issues.apache.org/jira/browse/JCLOUDS-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865723#comment-16865723
]
ASF subversion and git services commented on JCLOUDS-1166:
--
Commit 5d6a38f4fc8486bf9a7001fd147f13ea80f4afb0 in jclouds-labs's branch
refs/heads/master from Ignasi Barrera
[ https://gitbox.apache.org/repos/asf?p=jclouds-labs.git;h=5d6a38f ]
JCLOUDS-1166: Use shaded version of gson.internal package
> Remove uses of the 'com.google.gson.internal' package
> -
>
> Key: JCLOUDS-1166
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1166
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-chef, jclouds-core
>Affects Versions: 1.9.2
>Reporter: Ignasi Barrera
>Assignee: Ignasi Barrera
>Priority: Major
> Labels: gson
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Starting from Gson 2.6, the {{com.google.gson.internal}} packages are no
> longer exported in the OSGi bundles. This makes it impossible to use jclouds
> in an OSGi environment if upgrading to such versions of Gson.
> There is no change to add the exports back for that package (see [this
> discussion|https://github.com/google/gson/pull/916]), so we should stop using
> those classes.
> See also: http://markmail.org/message/olgebygfgdy3hwtm
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
