[jira] [Updated] (JCLOUDS-1564) Azure Blob Storage snapshot support
[ https://issues.apache.org/jira/browse/JCLOUDS-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1564: Issue Type: New Feature (was: Bug) > Azure Blob Storage snapshot support > --- > > Key: JCLOUDS-1564 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1564 > Project: jclouds > Issue Type: New Feature > Components: jclouds-blobstore >Affects Versions: 2.2.1 >Reporter: Rajesh Dubey >Priority: Major > > Azure Blob storage Rest API supports creating snapshot.I do not see it > implemented for Azure -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (JCLOUDS-1563) Cannot make S3 request with Access Point instead of Bucket
[
https://issues.apache.org/jira/browse/JCLOUDS-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1563:
Labels: aws-s3 s3 (was: s3)
> Cannot make S3 request with Access Point instead of Bucket
> --
>
> Key: JCLOUDS-1563
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1563
> Project: jclouds
> Issue Type: New Feature
> Components: jclouds-blobstore
>Affects Versions: 2.2.0
>Reporter: Blagoi Anastasov
>Priority: Major
> Labels: aws-s3, s3
>
> Hello,
> There is a pretty self-explanatory article about Access Points here:
> [https://docs.aws.amazon.com/AmazonS3/latest/dev/access-points.html]
>
> The problem is that GetObject and PutObject in jclouds-s3 and also the
> listBucket require the bucket name. However, AWS present a possibility to use
> Access Point instead the bucketName. It is in Blocking state because there is
> a client request for it.
> It will look like this:
> {{arn:aws:s3:us-west-2:123456789012:accesspoint/example}}
> {{}}
> Is there any chance to retrieve this scenario via existing jclouds version
> because I couldn't still do it?
>
> Best Regards,
> Blago{{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JCLOUDS-1563) Cannot make S3 request with Access Point instead of Bucket
[
https://issues.apache.org/jira/browse/JCLOUDS-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1563:
Priority: Major (was: Blocker)
> Cannot make S3 request with Access Point instead of Bucket
> --
>
> Key: JCLOUDS-1563
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1563
> Project: jclouds
> Issue Type: New Feature
> Components: jclouds-blobstore
>Affects Versions: 2.2.0
>Reporter: Blagoi Anastasov
>Priority: Major
> Labels: s3
>
> Hello,
> There is a pretty self-explanatory article about Access Points here:
> [https://docs.aws.amazon.com/AmazonS3/latest/dev/access-points.html]
>
> The problem is that GetObject and PutObject in jclouds-s3 and also the
> listBucket require the bucket name. However, AWS present a possibility to use
> Access Point instead the bucketName. It is in Blocking state because there is
> a client request for it.
> It will look like this:
> {{arn:aws:s3:us-west-2:123456789012:accesspoint/example}}
> {{}}
> Is there any chance to retrieve this scenario via existing jclouds version
> because I couldn't still do it?
>
> Best Regards,
> Blago{{}}
--
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=17241494#comment-17241494 ] Ignasi Barrera commented on JCLOUDS-1558: - The request filters can be defined [per-method|https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/rest/internal/RestAnnotationProcessor.java#L493-L515] as well, although they are [accummulative|https://github.com/apache/jclouds/blob/master/core/src/test/java/org/jclouds/rest/internal/RestAnnotationProcessorTest.java#L1460-L1486]. One option would be to remove the annotation from the class level and have it explicitly in each method. This way you can have a specific filter for the get container ACL, and configure the oauth-or-shared filter for all other emthods. > 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 > > 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-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=17240841#comment-17240841 ] Ignasi Barrera commented on JCLOUDS-1559: - Yes, I think it's reasonable to let that out of the scope of this issue. > 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 > > 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-1558) Azureblob Azure AD OAuth2 authentication support
[ https://issues.apache.org/jira/browse/JCLOUDS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240324#comment-17240324 ] Ignasi Barrera commented on JCLOUDS-1558: - Also, if there is a significant amount of code copied between ARM and Azureblob, it would probably make sense to create and "azure" directory in: https://github.com/apache/jclouds/tree/master/common > 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 > > 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-1558) Azureblob Azure AD OAuth2 authentication support
[
https://issues.apache.org/jira/browse/JCLOUDS-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240323#comment-17240323
]
Ignasi Barrera commented on JCLOUDS-1558:
-
Something that comes to my mind would be to define a new property that
configures the kind of authn to use ("oauth/sharedkey"), and based on that
property configure the filter. You could do that in a Guice module, similar to
what we do in the [OpenStack Keystone Auth module|http://example.com]. You'll
have to define a provider method that returns an implementation of the
HttpFilter. The filter is [loaded from the Guice injector based on the value of
the
annotation|https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/rest/internal/RestAnnotationProcessor.java#L498],
so probably you can just change the value there to just the HttpFilter
interface, or a custom interface or base class you could define. I think that
should work and could be clean. For backward-compatibility, the property should
default to the current authn.
Regarding tests, it is OK if you can't test with the China region. I'll ping
some folks I know there and see if we can get an account to try it. Apart from
that, creating the corresponding Mock tests would be enough. Take some API
methods and write a Mock test like the ones in the ARM provider. Mock tests use
the mockwebserver test framework to assert the requests that are sent. This
way, we can verify that for any given call, the requests that are generated are
exactly the expected ones. I think adding a Mock test that verifies that the
request is generated properly with the OAuth info is enough, as that code would
be common to all methods.
> 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
>
> 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-1554) Upgrade to Azure Blob API 2019-12-12
[ https://issues.apache.org/jira/browse/JCLOUDS-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17211055#comment-17211055 ] Ignasi Barrera commented on JCLOUDS-1554: - In the compute provider we had to deal with different versions depending on the API we were using. VM API used a different version than Disk API, etc. To provide more flexibility there without requiring to build a new context, we built a request filter that read the version from the context properties: * Filter: https://github.com/apache/jclouds/blob/master/providers/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/filters/ApiVersionFilter.java * Default values:https://github.com/apache/jclouds/blob/master/providers/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/AzureComputeProviderMetadata.java#L112-L138 * Usage: https://github.com/apache/jclouds/blob/master/providers/azurecompute-arm/src/main/java/org/jclouds/azurecompute/arm/features/AvailabilitySetApi.java#L51 I don't know if this applies here or it could be useful; it just came to my mind when reading the issue :) > Upgrade to Azure Blob API 2019-12-12 > > > Key: JCLOUDS-1554 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1554 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.2.1 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: azureblob > > This allows 5 GB single-part objects: > https://docs.microsoft.com/en-us/rest/api/storageservices/versioning-for-the-azure-storage-services -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1554) Upgrade to Azure Blob API 2019-12-12
[ https://issues.apache.org/jira/browse/JCLOUDS-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17209347#comment-17209347 ] Ignasi Barrera commented on JCLOUDS-1554: - Would it make sense to generalize the approach used in azure compute ARM so that the version for each specific API can be set via properties? > Upgrade to Azure Blob API 2019-12-12 > > > Key: JCLOUDS-1554 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1554 > Project: jclouds > Issue Type: Improvement > Components: jclouds-blobstore >Affects Versions: 2.2.1 >Reporter: Andrew Gaul >Assignee: Andrew Gaul >Priority: Major > Labels: azureblob > > This allows 5 GB single-part objects: > https://docs.microsoft.com/en-us/rest/api/storageservices/versioning-for-the-azure-storage-services -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (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:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1552.
-
Fix Version/s: 2.3.0
Resolution: Fixed
> 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
> Fix For: 2.3.0
>
> 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-1550) “NoSuchMethodErrors” due to multiple versions of com.google.guava:jar
[
https://issues.apache.org/jira/browse/JCLOUDS-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164560#comment-17164560
]
Ignasi Barrera commented on JCLOUDS-1550:
-
The {{jclouds/jclouds}} repo has been deprecated for a while. Please, use
{{apache/jclouds}}, as it is the up to date one and the Guava versions are
correct there.
We had a mirror job but I see that it has been failing for a while; this is why
you see a stale state in the deprecated repo. We'll look into that, but please,
do update your Git remotes and point to the Apache org repos.
> “NoSuchMethodErrors” due to multiple versions of com.google.guava:jar
> -
>
> Key: JCLOUDS-1550
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1550
> Project: jclouds
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Bing-ok
>Priority: Major
>
> Hi, there are multiple versions of _*com.google.guava:guava*_ in
> _*jclouds-master\providers\skalicloud-sdg-my*_. As shown in the following
> dependency tree, according to Maven's “nearest wins” strategy, only
> _*com.google.guava:guava:18.0*_ can be loaded,
> _*com.google.guava:guava:19.0*_ and _*com.google.guava:guava:22.0*_ will be
> shadowed.
> As _*com.google.guava:guava:22.0*_ has not been loaded during the building
> process, several methods are missing. However, the missing methods:
> 1. _*com.google.common.base.Preconditions: void
> checkArgument(boolean,java.lang.String,java.lang.Object)*_
> {noformat}
> paths--
> ()> jclouds-master\providers\skalicloud-sdg-my\target\classes
> org.jclouds.providers.internal.BaseProviderMetadata$Builder
> id(java.lang.String)>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> org.jclouds.providers.internal.BaseProviderMetadata$Builder
> linkedService(java.lang.String)>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> add(java.lang.Object)> Repositories\com\google\guava\guava\18.0\guava-18.0.jar
> boolean apply(java.lang.Object)>
> Repositories\org\apache\jclouds\jclouds-compute\2.3.0-SNAPSHOT\jclouds-compute-2.3.0-SNAPSHOT.jar
> boolean apply(org.jclouds.compute.domain.ComputeMetadata)>
> Repositories\org\apache\jclouds\jclouds-compute\2.3.0-SNAPSHOT\jclouds-compute-2.3.0-SNAPSHOT.jar
> checkArgument(boolean,java.lang.String,java.lang.Object)>{noformat}
> 2. _*com.google.common.base.Preconditions: void
> checkState(boolean,java.lang.String,java.lang.Object,java.lang.Object)*_
> {noformat}
> paths--
> ()> jclouds-master\providers\skalicloud-sdg-my\target\classes
> org.jclouds.providers.internal.BaseProviderMetadata$Builder
> id(java.lang.String)>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> org.jclouds.providers.internal.BaseProviderMetadata$Builder
> linkedService(java.lang.String)>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> add(java.lang.Object)> Repositories\com\google\guava\guava\18.0\guava-18.0.jar
> boolean apply(java.lang.Object)>
> Repositories\org\apache\jclouds\jclouds-compute\2.3.0-SNAPSHOT\jclouds-compute-2.3.0-SNAPSHOT.jar
> boolean apply(org.jclouds.compute.domain.ComputeMetadata)>
> Repositories\org\apache\jclouds\jclouds-compute\2.3.0-SNAPSHOT\jclouds-compute-2.3.0-SNAPSHOT.jar
>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> checkState(boolean,java.lang.String,java.lang.Object,java.lang.Object)>
> {noformat}
> 3. _*com.google.common.base.Preconditions: void
> checkArgument(boolean,java.lang.String,int)*_
> {noformat}
> paths--
> org.jclouds.skalicloud.SkaliCloudMalaysiaProviderMetadata$Builder
> fromProviderMetadata(org.jclouds.providers.ProviderMetadata)>
> jclouds-master\providers\skalicloud-sdg-my\target\classes
> org.jclouds.providers.internal.BaseProviderMetadata$Builder
> fromProviderMetadata(org.jclouds.providers.ProviderMetadata)>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> org.jclouds.providers.internal.BaseProviderMetadata$Builder
> linkedServices(java.lang.Iterable)>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> addAll(java.util.Collection,java.lang.Iterable)>
> Repositories\com\google\guava\guava\18.0\guava-18.0.jar
> java.util.Ite
[jira] [Updated] (JCLOUDS-1542) Java 11 warns of illegal reflective access
[
https://issues.apache.org/jira/browse/JCLOUDS-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1542:
Fix Version/s: 2.3.0
> 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
> 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] [Resolved] (JCLOUDS-1542) Java 11 warns of illegal reflective access
[
https://issues.apache.org/jira/browse/JCLOUDS-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1542.
-
Resolution: Fixed
> 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
> 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] [Updated] (JCLOUDS-1542) Java 11 warns of illegal reflective access
[
https://issues.apache.org/jira/browse/JCLOUDS-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1542:
Component/s: (was: jclouds-labs-google)
(was: jclouds-blobstore)
jclouds-core
> 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
> Time Spent: 2h
> 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] [Resolved] (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:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1533.
-
Fix Version/s: 2.2.1
2.3.0
Resolution: Fixed
> 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
> Fix For: 2.3.0, 2.2.1
>
> Time Spent: 40m
> 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=
Re: [jclouds/jclouds] JCLOUDS-1533 - Fix upload with SAS token when blob name contains slash (#1283)
nacx commented on this pull request.
Thanks for the fix!
This repository is deprecated, though. Could you update your fork and open the
PR against https://github.com/apache/jclouds ? Thanks!
> @@ -281,4 +284,19 @@ void appendUriPath(HttpRequest request, StringBuilder
> toSign) {
}
}
+ private String join(String[] parts, String delimiter) {
Can you use the Guava `Joiner` instead?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/1283#pullrequestreview-359663568
[jira] [Resolved] (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:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1538.
-
Fix Version/s: 2.2.1
2.3.0
Resolution: Fixed
> 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
> Fix For: 2.3.0, 2.2.1
>
> Time Spent: 0.5h
> 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)
Re: [jclouds/jclouds] JCLOUDS-1538: fix typo in rfc1123SimpleDateFormat (#1282)
Thanks! Mind opening it against the apache repo? https://github.com/apache/jclouds This is a deprecated read-only mirror as we moved to the Apache org. There we run the proper CI and PR tests, etc. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1282#issuecomment-577648853
[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=17021733#comment-17021733
]
Ignasi Barrera commented on JCLOUDS-1538:
-
Thanks for reporting and investigating! Mind opening a PR on
https://github.com/apache/jclouds with the fix?
> 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
>
> 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] [Resolved] (JCLOUDS-1536) SECURITY-1482 / CVE-2019-10368 (CSRF), CVE-2019-10369 (permission check)
[ https://issues.apache.org/jira/browse/JCLOUDS-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1536. - Resolution: Invalid > SECURITY-1482 / CVE-2019-10368 (CSRF), CVE-2019-10369 (permission check) > - > > Key: JCLOUDS-1536 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1536 > Project: jclouds > Issue Type: Bug >Affects Versions: 1.9.1 >Reporter: xingyunyang >Priority: Blocker > > *SECURITY-1482 / CVE-2019-10368 (CSRF), CVE-2019-10369 (permission check)* > JClouds Plugin did not perform permission checks on a method implementing > form validation. This allowed users with Overall/Read access to Jenkins to > connect to an attacker-specified URL using attacker-specified credentials IDs > obtained through another method, capturing credentials stored in Jenkins. > Additionally, this form validation method did not require POST requests, > resulting in a cross-site request forgery vulnerability. > > Has the problem been fixed？If the problem has been fixed, please tell me the > "commitid" for fixed version.Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1536) SECURITY-1482 / CVE-2019-10368 (CSRF), CVE-2019-10369 (permission check)
[ https://issues.apache.org/jira/browse/JCLOUDS-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17009579#comment-17009579 ] Ignasi Barrera commented on JCLOUDS-1536: - Thanks for the pointer, but we don't maintain the Jenkins jclouds plugin. Please refer to their issue tracker here: https://issues.jenkins-ci.org/issues/?jql=component%20%3D%20jclouds-plugin > SECURITY-1482 / CVE-2019-10368 (CSRF), CVE-2019-10369 (permission check) > - > > Key: JCLOUDS-1536 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1536 > Project: jclouds > Issue Type: Bug >Affects Versions: 1.9.1 >Reporter: xingyunyang >Priority: Blocker > > *SECURITY-1482 / CVE-2019-10368 (CSRF), CVE-2019-10369 (permission check)* > JClouds Plugin did not perform permission checks on a method implementing > form validation. This allowed users with Overall/Read access to Jenkins to > connect to an attacker-specified URL using attacker-specified credentials IDs > obtained through another method, capturing credentials stored in Jenkins. > Additionally, this form validation method did not require POST requests, > resulting in a cross-site request forgery vulnerability. > > Has the problem been fixed？If the problem has been fixed, please tell me the > "commitid" for fixed version.Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1531) Create p2 as part of maven build to make consumption in Eclipse apps easier
[ https://issues.apache.org/jira/browse/JCLOUDS-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987691#comment-16987691 ] Ignasi Barrera commented on JCLOUDS-1531: - Could you summarize the changes required in jclouds to support that? > Create p2 as part of maven build to make consumption in Eclipse apps easier > --- > > Key: JCLOUDS-1531 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1531 > Project: jclouds > Issue Type: Wish >Reporter: Markus Kuppe >Priority: Major > > Eclipse's primary repository format is p2. Consuming artifacts from a mixture > of p2 and (plain) maven repositories is brittle. As a workaround, I've been > building a p2 repository for jclouds [1]. Recently however, I learned about > a maven plugin [2] to easily create p2 repositories. Would a patch be > accepted into jclouds that adds p2 repository creation to jcloud's maven > build? > > [1][ > https://github.com/lemmy/jclouds2p2/|https://github.com/lemmy/jclouds2p2/] > [2] https://github.com/reficio/p2-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (JCLOUDS-1532) Update SSHJ + JSCH
[ https://issues.apache.org/jira/browse/JCLOUDS-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1532. - Resolution: Fixed > 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-1531) Create p2 as part of maven build to make consumption in Eclipse apps easier
[ https://issues.apache.org/jira/browse/JCLOUDS-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985496#comment-16985496 ] Ignasi Barrera commented on JCLOUDS-1531: - Honestly, it is a bit unlikely, as I don't think we'll be able to properly maintain that. We had issues maintaining our OSGi support recently, and that was one of the reasons the [jclouds-karaf|[https://github.com/apache/karaf-jclouds]] repo was moved to the Apache KAraf project. Can you use the stuff in the Karaf jclouds repo for your purposes? The Karaf team is actively maintaining that. The main issue we have in the active community is the lack of expertise on OSGi, and our inability to properly maintain related stuff. > Create p2 as part of maven build to make consumption in Eclipse apps easier > --- > > Key: JCLOUDS-1531 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1531 > Project: jclouds > Issue Type: Wish >Reporter: Markus Kuppe >Priority: Major > > Eclipse's primary repository format is p2. Consuming artifacts from a mixture > of p2 and (plain) maven repositories is brittle. As a workaround, I've been > building a p2 repository for jclouds [1]. Recently however, I learned about > a maven plugin [2] to easily create p2 repositories. Would a patch be > accepted into jclouds that adds p2 repository creation to jcloud's maven > build? > > [1][ > https://github.com/lemmy/jclouds2p2/|https://github.com/lemmy/jclouds2p2/] > [2] https://github.com/reficio/p2-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (JCLOUDS-1531) Create p2 as part of maven build to make consumption in Eclipse apps easier
[ https://issues.apache.org/jira/browse/JCLOUDS-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985496#comment-16985496 ] Ignasi Barrera edited comment on JCLOUDS-1531 at 12/1/19 8:18 AM: -- Honestly, it is a bit unlikely, as I don't think we'll be able to properly maintain that. We had issues maintaining our OSGi support recently, and that was one of the reasons the [jclouds-karaf|https://github.com/apache/karaf-jclouds] repo was moved to the Apache KAraf project. Can you use the stuff in the Karaf jclouds repo for your purposes? The Karaf team is actively maintaining that. The main issue we have in the active community is the lack of expertise on OSGi, and our inability to properly maintain related stuff. was (Author: nacx): Honestly, it is a bit unlikely, as I don't think we'll be able to properly maintain that. We had issues maintaining our OSGi support recently, and that was one of the reasons the [jclouds-karaf|[https://github.com/apache/karaf-jclouds]] repo was moved to the Apache KAraf project. Can you use the stuff in the Karaf jclouds repo for your purposes? The Karaf team is actively maintaining that. The main issue we have in the active community is the lack of expertise on OSGi, and our inability to properly maintain related stuff. > Create p2 as part of maven build to make consumption in Eclipse apps easier > --- > > Key: JCLOUDS-1531 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1531 > Project: jclouds > Issue Type: Wish >Reporter: Markus Kuppe >Priority: Major > > Eclipse's primary repository format is p2. Consuming artifacts from a mixture > of p2 and (plain) maven repositories is brittle. As a workaround, I've been > building a p2 repository for jclouds [1]. Recently however, I learned about > a maven plugin [2] to easily create p2 repositories. Would a patch be > accepted into jclouds that adds p2 repository creation to jcloud's maven > build? > > [1][ > https://github.com/lemmy/jclouds2p2/|https://github.com/lemmy/jclouds2p2/] > [2] https://github.com/reficio/p2-maven-plugin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (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:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1529. - Fix Version/s: 2.2.1 2.3.0 Resolution: Fixed > 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 > Fix For: 2.3.0, 2.2.1 > > Time Spent: 50m > 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 > com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:204) > at > com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:198) &
[jira] [Commented] (JCLOUDS-1530) azurecompute-arm retry/timeout to aggressive?
[
https://issues.apache.org/jira/browse/JCLOUDS-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984264#comment-16984264
]
Ignasi Barrera commented on JCLOUDS-1530:
-
Can you provide a minimal code we can use to reproduce this (obviously without
teh credentials)?
> azurecompute-arm retry/timeout to aggressive?
> -
>
> Key: JCLOUDS-1530
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1530
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.2.0
>Reporter: Markus Kuppe
>Priority: Major
> Labels: azurecompute-arm
>
> Trying to launch an Azure virtual machine (Ubuntu 18.04) fails with:
> {code:java}
> org.jclouds.compute.RunNodesException: error running 1 node
> group(azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345) location(eastus)
> image(Canonical) size(Standard_D14) options({loginPasswordPresent=true,
> taskName=bootstrap, inboundPorts=[22, 80, 443], scriptPresent=true,
> securityGroups=[/subscriptions/f1af7595-4102-45e0-8f00-dde13e40f865/resourceGroups/azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/providers/Microsoft.Network/networkSecurityGroups/jclouds-azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345],
> userMetadata={jclouds_group=azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345},
> resourceGroup=azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345,
> ipOptions=[IpOptions{subnet=/subscriptions/f1af7595-4102-45e0-8f00-dde13e40f865/resourceGroups/azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/providers/Microsoft.Network/virtualNetworks/jclouds-azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/subnets/jclouds-azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345,
> address=Optional.absent(), allocateNewPublicIp=true, publicIpId=null}]})
> Execution failures:0 error[s]
> Node failures:1) AuthorizationException on node
> azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345-348:
> org.jclouds.rest.AuthorizationException:
> (jclouds:pw[49bc707eedfa33bae83edc98b9a84014]@40.121.182.39:22)
> (jclouds:pw[49bc707eedfa33bae83edc98b9a84014]@40.121.182.39:22) error
> acquiring {hostAndPort=40.121.182.39:22, loginUser=jclouds, ssh=null,
> connectTimeout=6, sessionTimeout=6} (not retryable): Exhausted
> available authentication methods
> at org.jclouds.sshj.SshjSshClient.propagate(SshjSshClient.java:394)
> at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:215)
> at org.jclouds.sshj.SshjSshClient.connect(SshjSshClient.java:224)
> at
> org.jclouds.compute.callables.RunScriptOnNodeAsInitScriptUsingSsh.call(RunScriptOnNodeAsInitScriptUsingSsh.java:72)
> at
> org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:123)
> at
> org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:144)
> at
> org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:50)
> at
> com.google.common.util.concurrent.AbstractTransformFuture$TransformFuture.doTransform(AbstractTransformFuture.java:239)
> at
> com.google.common.util.concurrent.AbstractTransformFuture$TransformFuture.doTransform(AbstractTransformFuture.java:229)
> at
> com.google.common.util.concurrent.AbstractTransformFuture.run(AbstractTransformFuture.java:130)
> at
> com.google.common.util.concurrent.MoreExecutors$5$1.run(MoreExecutors.java:952)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: net.schmizz.sshj.userauth.UserAuthException: Exhausted available
> authentication methods
> at net.schmizz.sshj.SSHClient.auth(SSHClient.java:230)
> at net.schmizz.sshj.SSHClient.auth(SSHClient.java:205)
> at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:291)
> at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:261)
> at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:245)
> at
> org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:166)
> at
> org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:50)
> at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:195)
> ... 12 more
> 1 error[s]
> at
[jira] [Updated] (JCLOUDS-1530) azurecompute-arm retry/timeout to aggressive?
[
https://issues.apache.org/jira/browse/JCLOUDS-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1530:
Labels: azurecompute-arm (was: )
> azurecompute-arm retry/timeout to aggressive?
> -
>
> Key: JCLOUDS-1530
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1530
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.2.0
>Reporter: Markus Kuppe
>Priority: Major
> Labels: azurecompute-arm
>
> Trying to launch an Azure virtual machine (Ubuntu 18.04) fails with:
> {code:java}
> org.jclouds.compute.RunNodesException: error running 1 node
> group(azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345) location(eastus)
> image(Canonical) size(Standard_D14) options({loginPasswordPresent=true,
> taskName=bootstrap, inboundPorts=[22, 80, 443], scriptPresent=true,
> securityGroups=[/subscriptions/f1af7595-4102-45e0-8f00-dde13e40f865/resourceGroups/azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/providers/Microsoft.Network/networkSecurityGroups/jclouds-azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345],
> userMetadata={jclouds_group=azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345},
> resourceGroup=azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345,
> ipOptions=[IpOptions{subnet=/subscriptions/f1af7595-4102-45e0-8f00-dde13e40f865/resourceGroups/azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/providers/Microsoft.Network/virtualNetworks/jclouds-azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/subnets/jclouds-azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345,
> address=Optional.absent(), allocateNewPublicIp=true, publicIpId=null}]})
> Execution failures:0 error[s]
> Node failures:1) AuthorizationException on node
> azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345/azure-b4e90bfc-8f15-4c40-b546-a41f61ee7345-348:
> org.jclouds.rest.AuthorizationException:
> (jclouds:pw[49bc707eedfa33bae83edc98b9a84014]@40.121.182.39:22)
> (jclouds:pw[49bc707eedfa33bae83edc98b9a84014]@40.121.182.39:22) error
> acquiring {hostAndPort=40.121.182.39:22, loginUser=jclouds, ssh=null,
> connectTimeout=6, sessionTimeout=6} (not retryable): Exhausted
> available authentication methods
> at org.jclouds.sshj.SshjSshClient.propagate(SshjSshClient.java:394)
> at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:215)
> at org.jclouds.sshj.SshjSshClient.connect(SshjSshClient.java:224)
> at
> org.jclouds.compute.callables.RunScriptOnNodeAsInitScriptUsingSsh.call(RunScriptOnNodeAsInitScriptUsingSsh.java:72)
> at
> org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.call(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:123)
> at
> org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:144)
> at
> org.jclouds.compute.strategy.CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.apply(CustomizeNodeAndAddToGoodMapOrPutExceptionIntoBadMap.java:50)
> at
> com.google.common.util.concurrent.AbstractTransformFuture$TransformFuture.doTransform(AbstractTransformFuture.java:239)
> at
> com.google.common.util.concurrent.AbstractTransformFuture$TransformFuture.doTransform(AbstractTransformFuture.java:229)
> at
> com.google.common.util.concurrent.AbstractTransformFuture.run(AbstractTransformFuture.java:130)
> at
> com.google.common.util.concurrent.MoreExecutors$5$1.run(MoreExecutors.java:952)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: net.schmizz.sshj.userauth.UserAuthException: Exhausted available
> authentication methods
> at net.schmizz.sshj.SSHClient.auth(SSHClient.java:230)
> at net.schmizz.sshj.SSHClient.auth(SSHClient.java:205)
> at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:291)
> at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:261)
> at net.schmizz.sshj.SSHClient.authPassword(SSHClient.java:245)
> at
> org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:166)
> at
> org.jclouds.sshj.SSHClientConnection.create(SSHClientConnection.java:50)
> at org.jclouds.sshj.SshjSshClient.acquire(SshjSshClient.java:195)
> ... 12 more
> 1 error[s]
> at
> org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(BaseComputeService.java:225)
>
Re: [jclouds/jclouds] JCLOUDS-1529: Do not export org.jclouds.json.gson.internal because it causes a (#1281)
Thanks! Mind opening the PR against https://github.com/apache/jclouds instead? This repo is deprecated and we're only keeping it in sync to help people, but will eventually die. All CI builds and tests are not running here, only in the Apache one, so I'd appreciate if you could do that. Also, just opening against master is fine. I'll cherry-pick the changes to the bugfix branch. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1281#issuecomment-559167473
[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=16983694#comment-16983694 ] Ignasi Barrera commented on JCLOUDS-1529: - There is no timeframe, but I would be happy to trigger a release as this is a blocker in OSGi environments. Mind raising a PR with the fix? > 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 > > 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 > com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:204) > at > com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:198) > 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=16983662#comment-16983662
]
Ignasi Barrera commented on JCLOUDS-1529:
-
That's weird, according to the [plugin
docs|http://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#instructions],
the second version should work fine:
{noformat}
The list of package patterns is ordered and earlier patterns are applied before
later patterns. For example, if you specify "org.foo.,!org.foo.impl" the second
pattern has no effect since all org.foo packages have already been selected by
the first pattern. Instead, you should specify "!org.foo.impl,org.foo.", which
will export all org.foo packages except org.foo.impl.{noformat}
> 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
>
> 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
[jira] [Comment Edited] (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=16983581#comment-16983581
]
Ignasi Barrera edited comment on JCLOUDS-1529 at 11/27/19 2:36 PM:
---
Hmmm I think we could try changing the [jclouds-core
exports|https://github.com/apache/jclouds/blob/master/core/pom.xml#L42] to
something like:
{code:xml}
org.jclouds*;version=${project.version};-noimport:=true
!org.jclouds.json.gson.internal*
{code}
Could you try this change and see if it fixes the issue?
was (Author: nacx):
Hmmm I think we could try changing the [jclouds-core
exports|https://github.com/apache/jclouds/blob/master/core/pom.xml#L42] to
something like:
{code:xml}
org.jclouds*;version=${project.version};-noimport:=true
org.jclouds.json.gson.internal*
{code}
Could you try this change and see if it fixes the issue?
> 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
>
> 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.goog
[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=16983581#comment-16983581
]
Ignasi Barrera commented on JCLOUDS-1529:
-
Hmmm I think we could try changing the [jclouds-core
exports|https://github.com/apache/jclouds/blob/master/core/pom.xml#L42] to
something like:
{code:xml}
org.jclouds*;version=${project.version};-noimport:=true
org.jclouds.json.gson.internal*
{code}
Could you try this change and see if it fixes the issue?
> 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
>
> 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
> com.google.inject.i
[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=16983436#comment-16983436 ] Ignasi Barrera commented on JCLOUDS-1529: - Can you try removing the com.google.gson from your deployment? jclouds already provides that library, but with some packages being relocated so they can be exported. > 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 > > 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 > com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:204) > at > com.google.inject.internal
[jira] [Updated] (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:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1528: Component/s: jclouds-core > 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 > Components: jclouds-core >Reporter: Colm O hEigeartaigh >Priority: Minor > Fix For: 2.3.0 > > Time Spent: 0.5h > 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] [Resolved] (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:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1528. - Resolution: Fixed > 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: 0.5h > 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-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=16981376#comment-16981376
]
Ignasi Barrera commented on JCLOUDS-1166:
-
The issue is still open because jclouds is still using those packages. 2.2.0,
however, was released with a workaround using shading and package relocation so
the jclouds components don't break in OSGi environments.
> 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 50m
> 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
(v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1527) Azure compute rate limit exceeded exception during the build of image cache
[
https://issues.apache.org/jira/browse/JCLOUDS-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16978190#comment-16978190
]
Ignasi Barrera commented on JCLOUDS-1527:
-
Looking at those loops, I think it would make sense to restrict the versions
just to {{latest}} by default, and have a context property to enable listing
all versions for each SKU. The Operating system version (such as 7, for CentOS)
is usually stored in the SKU, and there might be many versions for that OS
version. I think a reasonable approach is to just list {{latest}} by default,
and that would remove N iterations for each SKU, which should considerably
reduce the network calls.
Would that work?
> Azure compute rate limit exceeded exception during the build of image cache
> ---
>
> Key: JCLOUDS-1527
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1527
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.1.3
>Reporter: Simone
>Priority: Critical
> Labels: azurecompute-arm
>
> Here the exception:
> {noformat}
> org.jclouds.azurecompute.arm.exceptions.AzureComputeRateLimitExceededException:
> HTTP/1.1 429
> {}
> at
> org.jclouds.azurecompute.arm.handlers.AzureComputeErrorHandler.handleError(AzureComputeErrorHandler.java:79)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:138)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:107)
> 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:84)
> at com.sun.proxy.$Proxy267.getVersion
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.getImagesFromPublisher(AzureComputeServiceAdapter.java:212)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listImagesByLocation(AzureComputeServiceAdapter.java:226)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listImages(AzureComputeServiceAdapter.java:255)
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$2.get(ComputeServiceAdapterContextModule.java:121)
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$2.get(ComputeServiceAdapterContextModule.java:118)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:75)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3628)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2336)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2295)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2208)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4053)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4057)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4986)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.get(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:150)
> at
> org.jclouds.compute.suppliers.ImageCacheSupplier.get(ImageCacheSupplier.java:106)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.getImages(TemplateBuilderImpl.java:853)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.build(TemplateBuilderImpl.java:665)
> {noformat}
> I use the Azure passing the imageId to template builder, I think that the
> cache is usefull in my case, but passing the override parameter:
> "jclouds.azurecompute.a
[jira] [Commented] (JCLOUDS-1527) Azure compute rate limit exceeded exception during the build of image cache
[
https://issues.apache.org/jira/browse/JCLOUDS-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976420#comment-16976420
]
Ignasi Barrera commented on JCLOUDS-1527:
-
Changing this is not that trivial. The image cache list is not only used when
provisioning VMs, but also in many other places, such as when listing images,
or even when listing existing VMs (there is a process that tries to get the
image for each node that uses the image cache). If the list of images is empty,
many things will break, so I don't think changing that line is the right fix.
In the end, the TemplateBuilder semantics is just about the selection of images
from the existing image set, so there is no point in making it work when there
are no images there.
The right fix should be properly adjusting the publisher list to the one that
contains the image(s) you are using. Can you configure that instead?
> Azure compute rate limit exceeded exception during the build of image cache
> ---
>
> Key: JCLOUDS-1527
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1527
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.1.3
>Reporter: Simone
>Priority: Critical
> Labels: azurecompute-arm
>
> Here the exception:
> {noformat}
> org.jclouds.azurecompute.arm.exceptions.AzureComputeRateLimitExceededException:
> HTTP/1.1 429
> {}
> at
> org.jclouds.azurecompute.arm.handlers.AzureComputeErrorHandler.handleError(AzureComputeErrorHandler.java:79)
> at
> org.jclouds.http.handlers.DelegatingErrorHandler.handleError(DelegatingErrorHandler.java:65)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.shouldContinue(BaseHttpCommandExecutorService.java:138)
> at
> org.jclouds.http.internal.BaseHttpCommandExecutorService.invoke(BaseHttpCommandExecutorService.java:107)
> 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:84)
> at com.sun.proxy.$Proxy267.getVersion
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.getImagesFromPublisher(AzureComputeServiceAdapter.java:212)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listImagesByLocation(AzureComputeServiceAdapter.java:226)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listImages(AzureComputeServiceAdapter.java:255)
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$2.get(ComputeServiceAdapterContextModule.java:121)
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$2.get(ComputeServiceAdapterContextModule.java:118)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:75)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3628)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2336)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2295)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2208)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4053)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4057)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4986)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.get(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:150)
> at
> org.jclouds.compute.suppliers.ImageCacheSupplier.get(ImageCacheSupplier.java:106)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.getImages(TemplateBuilderImpl.java:853)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.build(TemplateBuilderI
[jira] [Resolved] (JCLOUDS-1525) Update xmlbuilder dependency
[
https://issues.apache.org/jira/browse/JCLOUDS-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1525.
-
Fix Version/s: (was: 2.2.1)
Resolution: Fixed
> 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
>
> Time Spent: 0.5h
> 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] [Resolved] (JCLOUDS-1526) Update BouncyCastle dependency
[ https://issues.apache.org/jira/browse/JCLOUDS-1526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1526. - Fix Version/s: (was: 2.2.1) Resolution: Fixed > 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 > > 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] [Resolved] (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:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1520.
-
Fix Version/s: 2.2.1
2.3.0
Resolution: Fixed
> 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
> Fix For: 2.3.0, 2.2.1
>
> Attachments: screenshot-1.png
>
> Time Spent: 1h 20m
> 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
&
[jira] [Updated] (JCLOUDS-1458) Create Dimension Data Provider Guide
[ https://issues.apache.org/jira/browse/JCLOUDS-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1458: Fix Version/s: (was: 2.2.0) > Create Dimension Data Provider Guide > > > Key: JCLOUDS-1458 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1458 > Project: jclouds > Issue Type: Task >Reporter: Trevor Flanagan >Priority: Major > Labels: dimensiondata > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (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:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1516: Fix Version/s: (was: 2.2.0) > 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"
[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=16950255#comment-16950255
]
Ignasi Barrera commented on JCLOUDS-1520:
-
Oh, apologies for the confusion. Absolutely :) It applies to the supplier
itself. I did not realize that the SSL context was being created in every
{{get}} in the SSLModule, as I just read the code in the issue but not the
jclouds code itself :)
Your patch looks good. Mind opening a pull request?
> 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
>
>
> 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 ]
[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=16950250#comment-16950250 ] Ignasi Barrera commented on JCLOUDS-1470: - There are some issues like JCLOUDS-1333 round the upgrade of some of the core dependencies of the project. That is also preventing us from upgrading to newer Java versions. However, this is a community project and current availability from most of the core members is very limited and it is unlikely that we can make that happen in a timely manner. We would, however, be very happy to help anyone from the community that wants to champion this and to provide any help and guidance to anyone that wants to contribute a patch to upgrade the dependencies. Contributions are very welcome! > 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] [Comment Edited] (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=16950249#comment-16950249
]
Ignasi Barrera edited comment on JCLOUDS-1520 at 10/13/19 9:08 AM:
---
Interesting. Does it work if instead, you remove that binding line and move the
config to a provider method like the following one?
{code:java}
@Singleton
@Named("untrusted")
protected final Supplier
provideUntrustedContext(UntrustedSSLContextSupplier untrusted) {
return untrusted;
}
{code}
was (Author: nacx):
Does it work if instead, you remove that binding line and move the config to a
provider method like the following one?
{code:java}
@Singleton
@Named("untrusted")
protected final Supplier
provideUntrustedContext(UntrustedSSLContextSupplier untrusted) {
return untrusted;
}
{code}
> 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
>
>
> 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-reques
[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=16950249#comment-16950249
]
Ignasi Barrera commented on JCLOUDS-1520:
-
Does it work if instead, you remove that binding line and move the config to a
provider method like the following one?
{code:java}
@Singleton
@Named("untrusted")
protected final Supplier
provideUntrustedContext(UntrustedSSLContextSupplier untrusted) {
return untrusted;
}
{code}
> 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
>
>
> 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 ]
&g
[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=16950237#comment-16950237
]
Ignasi Barrera commented on JCLOUDS-1520:
-
Thanks for the detailed report [~roded]!
Instead of overriding the supplier, could you try this approach and see if it
works? It changes instead how the supplier is bound to the Guice context:
{code:java}
bind(new TypeLiteral>() {
}).annotatedWith(Names.named("untrusted")).to(new
TypeLiteral() {
}).in(Scopes.SINGLETON);
{code}
Are you willing to go one step further and open a pull request?
> 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
>
> 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
[jira] [Commented] (JCLOUDS-1518) Next jclouds release
[ https://issues.apache.org/jira/browse/JCLOUDS-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943591#comment-16943591 ] Ignasi Barrera commented on JCLOUDS-1518: - Done > Next jclouds release > > > Key: JCLOUDS-1518 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1518 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Reporter: Vasil Bozhurski >Priority: Major > > For Azure Blobstore we at SAP require authentication with SAS token which I > saw was completed in JCLOUDS-1428 and marked for 2.1.3/2.2.0 but it is yet to > be released. This is currently a blocker for us so when can we expect the > next jclouds release? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1518) Next jclouds release
[ https://issues.apache.org/jira/browse/JCLOUDS-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16943378#comment-16943378 ] Ignasi Barrera commented on JCLOUDS-1518: - I think we could be able to cut the 2.1.3 release next week. Sounds good? > Next jclouds release > > > Key: JCLOUDS-1518 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1518 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Reporter: Vasil Bozhurski >Priority: Major > > For Azure Blobstore we at SAP require authentication with SAS token which I > saw was completed in JCLOUDS-1428 and marked for 2.1.3/2.2.0 but it is yet to > be released. This is currently a blocker for us so when can we expect the > next jclouds release? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1517) google could - can't handle service account without scopes
[
https://issues.apache.org/jira/browse/JCLOUDS-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16941708#comment-16941708
]
Ignasi Barrera commented on JCLOUDS-1517:
-
Thanks for reporting.
In the codebase, in general we favor empty collections versus null ones, so the
fix should be as easy as changing that method to initialize the scopes to an
empty list if the parameter is null. Something like:
{code}
@SerializedNames({ "email", "scopes" })
public static ServiceAccount create(String email, List scopes) {
return new AutoValue_Instance_ServiceAccount(email, copyOf(scopes));
}
{code}
Do you wanna try opening a pull request with the patch?
> google could - can't handle service account without scopes
> --
>
> Key: JCLOUDS-1517
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1517
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-labs-google
>Reporter: Yasei
>Priority: Major
>
> When getting the active instance list (listNodesDetailsMatching), the code is
> issuing an instanceAggregatedList request to google, expecting to get
> serviceAccounts with email and scopes - I have an example that does not have
> scopes, so the code fail with the below stack trace.
> This is a snippet from my response:
> serviceAccounts: [{
> serviceAccounts: [{ email: elasticsearch - sa @ xx - xx -
> xxx.iam.gserviceaccount.com
> }
> ],
> my other accounts do have scopes:
> serviceAccounts: [{
> serviceAccounts: [{ email: xxx - compute @ developer.gserviceaccount.com,
> scopes: [
> https: //www.googleapis.com/auth/cloud.useraccounts.readonly ,
> https: //www.googleapis.com/auth/devstorage.read_only ,
> https: //www.googleapis.com/auth/logging.write ,
> https: //www.googleapis.com/auth/monitoring.write ,
> https: //www.googleapis.com/auth/cloudruntimeconfig
> ] } ],
> I guess 'scopes' should be optional.
> The code is this:
> [https://github.com/apache/jclouds/blob/master/providers/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java#L164]
> Stack trace:
> SEVERE: Error parsing input: Null scopes
> java.lang.NullPointerException: Null scopes at
> org.jclouds.googlecomputeengine.domain.AutoValue_Instance_ServiceAccount.(AutoValue_Instance_ServiceAccount.java:21)
> at
> org.jclouds.googlecomputeengine.domain.Instance$ServiceAccount.create(Instance.java:166)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> com.google.common.reflect.Invokable$MethodInvokable.invokeInternal(Invokable.java:197)
> at com.google.common.reflect.Invokable.invoke(Invokable.java:102) at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.newInstance(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:224)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:204)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.readAndBuild(NullFilteringTypeAdapterFactories.java:95)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:83)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:62)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$ParameterReader.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:272)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.java:184)
> at
> org.jclouds.googlecloud.config.ListPageAdapterFactory$ListPageAdapter.readItems(ListPageAdapterFactory.java:73)
> at
> org.jclouds.googlecloud.config.ListPageAdapterFactory$ListPageAdapter.readAggregate(ListPageAdapterFactory.java:89)
> at
> org.jclouds.googlecloud.config.ListPageAdapterFactory$ListPageAdapter.read(ListPageAdapterFactory.java:58)
> at
> org.jclouds.googlecloud.config.ListPageAdapterFactory$ListPageAdapter.read(ListPageAdapterFactory.java:36)
> at com.googl
[jira] [Resolved] (JCLOUDS-1514) Azurecompute-arm add disk storage types on disk create/update
[ https://issues.apache.org/jira/browse/JCLOUDS-1514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1514. - Fix Version/s: 2.1.3 2.2.0 Resolution: Fixed > Azurecompute-arm add disk storage types on disk create/update > - > > Key: JCLOUDS-1514 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1514 > Project: jclouds > Issue Type: Improvement > Components: jclouds-compute >Affects Versions: 2.1.2 >Reporter: Simone >Priority: Minor > Labels: azurecompute-arm > Fix For: 2.2.0, 2.1.3 > > > It is not possible to deploy SSD disks, to add that functionality we need to > add the sku parameter in the update/create request > [Azure > documentation|https://docs.microsoft.com/en-us/rest/api/compute/disks/createorupdate] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JCLOUDS-1225) Guava 21 compatibility
[ https://issues.apache.org/jira/browse/JCLOUDS-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16930704#comment-16930704 ] Ignasi Barrera commented on JCLOUDS-1225: - FWIW, here is the matrix of supported jdk, guava and guice versions: https://builds.apache.org/view/J/view/jclouds/job/jclouds-compat/ Contributions to upgrade the versions of those dependencies so we can use newer JDKs to build jclouds would be very very much appreciated! :) > Guava 21 compatibility > -- > > Key: JCLOUDS-1225 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1225 > Project: jclouds > Issue Type: Improvement > Components: jclouds-core >Affects Versions: 2.0.0 >Reporter: Ian Springer >Assignee: Andrew Gaul >Priority: Major > Labels: guava > Fix For: 2.1.0 > > > The below classes use com.google.common.base.Objects.ToStringHelper, which > has been deprecated since Guava 18, and has been removed in Guava 21. This > makes it impossible to use jclouds in a project using Guava 21. Please either > upgrade to Guava 18+ and switch to using > com.google.common.base.MoreObjects.ToStringHelper, or drop the usage of > ToStringHelper altogether. This will allow my project to upgrade to Guava 21 > without having to use a fork of jclouds. > * org/jclouds/apis/internal/BaseApiMetadata.java > * org/jclouds/domain/internal/LocationImpl.java > * org/jclouds/domain/internal/MutableResourceMetadataImpl.java > * org/jclouds/domain/internal/ResourceMetadataImpl.java > * org/jclouds/http/HttpMessage.java > * org/jclouds/http/HttpRequest.java > * org/jclouds/http/HttpResponse.java > * org/jclouds/internal/BaseView.java > * org/jclouds/providers/internal/BaseProviderMetadata.java > * org/jclouds/reflect/InvocationSuccess.java > * org/jclouds/rest/internal/BaseHttpApiMetadata.java > * org/jclouds/rest/suppliers/URIFromStringSupplier.java -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (JCLOUDS-1506) Azurecompute-arm add tags on disk create/update
[ https://issues.apache.org/jira/browse/JCLOUDS-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1506. - Resolution: Fixed Fix Version/s: 2.1.3 2.2.0 > Azurecompute-arm add tags on disk create/update > --- > > Key: JCLOUDS-1506 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1506 > Project: jclouds > Issue Type: Improvement > Components: jclouds-compute >Reporter: Simone >Priority: Major > Labels: azurecompute-arm > Fix For: 2.2.0, 2.1.3 > > > At the moment is not possible to add tags on azure disks, I made a PR on > [github|https://github.com/jclouds/jclouds/pull/1277] -- This message was sent by Atlassian JIRA (v7.6.14#76016)
Re: [jclouds/jclouds] Add tag support to azure disks (#1277)
Closed #1277. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1277#event-2546055775
Re: [jclouds/jclouds] Add tag support to azure disks (#1277)
Squashed and pushed to [master](https://github.com/apache/jclouds/commit/fcf72e5ea58bcbe16b25f2a12c29ca55cc7c000c) and [2.1.x](https://github.com/apache/jclouds/commit/bd59263d470f4307fe1a70a064e11c1ebeea064a). Thanks! Please consider opening upcoming PRs on the [apache/jclouds](https://github.com/apache/jclouds) repo. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1277#issuecomment-519869490
Re: [jclouds/jclouds] Add tag support to azure disks (#1277)
Unit (mock) tests run on every build. For live tests, which actually cost money :), we run them before a release, mostly using our accounts, so we can't afford run them all. [Some providers](https://cwiki.apache.org/confluence/display/JCLOUDS/Test+Provider+Thanks) help the project with testing accounts. We run the tests for those on every release for sure, and we have a (very) few of them [running weekly](https://builds.apache.org/view/J/view/jclouds/job/jclouds-with-credentials/). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1277#issuecomment-519867585
Re: [jclouds/jclouds] Add tag support to azure disks (#1277)
Thanks, @pimuzzo! Can you add the corresponding test in the `DiskApiMockTest`? It should be as easy as copying the existing create test and checking that the payload includes the tags. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1277#issuecomment-519645773
[jira] [Resolved] (JCLOUDS-1500) Update gson to 2.8.5
[ https://issues.apache.org/jira/browse/JCLOUDS-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1500. - Resolution: Fixed > 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=16876514#comment-16876514
]
Ignasi Barrera commented on JCLOUDS-1166:
-
I think it would make sense to have a release once we've merged this:
https://github.com/apache/jclouds/pull/29
> 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 50m
> 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)
Re: [jclouds/jclouds] Add OSGi exports to jclouds-gson (#38) (753bd8d)
Yep. It is a PITA to make the maven bundle plugin and the shade plugin work together to produce proper OSGi metadata in the generated manifest file. All this jclouds gson thing and the split in two modules is the only way we've found to cleanly 樂 fix that. The idea is that the only stuff exposed and used by other projects should be the `jclouds-gson` one, and the exclusion should [be implicitly be there](https://github.com/apache/jclouds/blob/master/project/pom.xml#L257-L277) already. For example, the gson related dependencies for `jclouds-core` are: ```bash nacx ~/src/asf/jclouds (master *) $ mvn dependency:tree -pl core | grep gson -B2 -A2 [INFO] | | \- com.squareup.okio:okio:jar:1.2.0:test [INFO] | \- org.bouncycastle:bcprov-jdk15on:jar:1.50:test [INFO] +- org.apache.jclouds:jclouds-gson:jar:2.2.0-SNAPSHOT:compile [INFO] +- com.google.guava:guava:jar:21.0:compile [INFO] +- org.osgi:org.osgi.core:jar:4.2.0:provided ``` Does this address your concern? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/commit/753bd8d78178112029bb9cc1b13a8d1e9f041cf8#commitcomment-34139876
[jira] [Commented] (JCLOUDS-1504) BlobStore.list(container, ListContainerOptions) returns collection containing null elements
[
https://issues.apache.org/jira/browse/JCLOUDS-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16871511#comment-16871511
]
Ignasi Barrera commented on JCLOUDS-1504:
-
We should then try to understand that {{sometimes}} and see what causes that
behavior. Can you enable the wire logs and check what does AWS return when you
see the null objects?
> BlobStore.list(container, ListContainerOptions) returns collection containing
> null elements
>
>
> Key: JCLOUDS-1504
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1504
> Project: jclouds
> Issue Type: Bug
>Reporter: Енчо Белезирев
>Priority: Blocker
>
> Hello,
> I am an SAP developer and we are using jclouds for the communication with our
> blob stores.
> We have issue with the querying of the StorageMetadata for some blobs. We are
> using the method from the BlobStore -
> {code:java}
> PageSet list(String container,
> ListContainerOptions options);{code}
> However, when we are using the method, we are providing
> ListContainerOptions.Builder.withDetails() because we want to take directly
> the userMetadata field from the StorageMetadata object and to use it later
> on. Here comes the problem, sometimes, when the method is being executed, the
> list that is being returned contains null objects. This is a problem because
> we want each StorageMetadata to be non-null.
> I have validated our entries in the container and it seemed that there are no
> suspicious entries in it(which might cause the issue).
> Could you share some information what could have caused the issue and
> eventually, is there a way to workaround this?
>
> We are using aws-s3 implementation of the blob store.
>
--
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=16869300#comment-16869300
]
Ignasi Barrera commented on JCLOUDS-1166:
-
The uses of the internal gson package have been relocated to a jclouds one and
using it in OSGi should no longer be an issue.
With these fixes in place we should be able to go ahead and upgrade Gson and
other dependencies that were blocking us.
> 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 50m
> 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)
[jira] [Comment Edited] (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=16864302#comment-16864302
]
Ignasi Barrera edited comment on JCLOUDS-1166 at 6/17/19 8:52 AM:
--
I agree it is not ideal, but it fixes the immediate issue and it does not
prevent jclouds from upgrading (see that only the internal offending package is
renamed, the rest remains exactly the same.
The ideal solution would be to remove the need of that package, but it requires
more effort, and jclouds is a pure volunteer project.
* Are you stepping in to fix it the right way?
* This has been open for a long time. Lots of affected users. No real work on
this from anyone. If someone is willing to spend the time to contribute a
better fix, I'd be more than happy to review and merge it. Otherwise I'd
suggest to move forward and nblock people.
As said, this is a purely volunteer project and we are happy to accept
contributions... When they come :)
was (Author: nacx):
I agree it is not ideal, but it fixes the immediate issue and it does not
prevent jclouds from upgrading (see that only the internal offending package is
renamed, the rest remains exactly the same.
The ideal solution would be to remove the need of that package, but it requires
more effort, and jclouds is a pure volunteer project.
* Are you stepping to fix it the right way?
* This has been open for a long time. Lots of affected users. No real work on
this from anyone. If someone is willing to spend the time to contribute a
better fix, I'd be more than happy to review and merge it. Otherwise I'd
suggest to move forward and nblock people.
As said, this is a purely volunteer project and we are happy to accept
contributions... When they come :)
> 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: 40m
> 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)
[jira] [Resolved] (JCLOUDS-1503) Azurecompute-arm deploy doesn't work
[
https://issues.apache.org/jira/browse/JCLOUDS-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1503.
-
Resolution: Fixed
Fix Version/s: 2.1.3
2.2.0
> Azurecompute-arm deploy doesn't work
>
>
> Key: JCLOUDS-1503
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1503
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.1.2
>Reporter: Simone
>Priority: Blocker
> Labels: azurecompute-arm, compute
> Fix For: 2.2.0, 2.1.3
>
> Attachments: Schermata del 2019-06-14 10-34-17.png, jclouds-wire.log,
> locations.json
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Deploying on azure/northeurope I have this error from this morning, I am
> passing northeurope as locationId
> Stacktrace:
> {noformat}
> java.lang.NumberFormatException: For input string: "54.39"
> at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
> at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:538)
> at com.google.gson.stream.JsonReader.nextDouble(JsonReader.java:925)
> at com.google.gson.Gson$3.read(Gson.java:268)
> at com.google.gson.Gson$3.read(Gson.java:262)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$ParameterReader.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.j$
> va:273)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflec$
> iveTypeAdapterFactory.java:185)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.readAndBuild(NullFilteringTypeAdapterFactories.java:95)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:83)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:62)
>
> at com.google.gson.Gson.fromJson(Gson.java:861)
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:80)
>
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:44)
>
> 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:84)
>
> at com.sun.proxy.$Proxy214.list(Unknown Source)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listLocations(AzureComputeServiceAdapter.java:307)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:84)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:81)
>
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTi$
> eOutButNotOnAuthorizationExceptionSupplier.java:75)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTim
> eOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3628)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2336)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2295)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2208)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4053)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4057)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4986)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.get(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:150)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.locationId(TemplateBuilderImpl.java:603)
> {noformat}
--
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=16864302#comment-16864302
]
Ignasi Barrera commented on JCLOUDS-1166:
-
I agree it is not ideal, but it fixes the immediate issue and it does not
prevent jclouds from upgrading (see that only the internal offending package is
renamed, the rest remains exactly the same.
The ideal solution would be to remove the need of that package, but it requires
more effort, and jclouds is a pure volunteer project.
* Are you stepping to fix it the right way?
* This has been open for a long time. Lots of affected users. No real work on
this from anyone. If someone is willing to spend the time to contribute a
better fix, I'd be more than happy to review and merge it. Otherwise I'd
suggest to move forward and nblock people.
As said, this is a purely volunteer project and we are happy to accept
contributions... When they come :)
> 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: 10m
> 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)
[jira] [Commented] (JCLOUDS-1503) Azurecompute-arm deploy doesn't work
[
https://issues.apache.org/jira/browse/JCLOUDS-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16864142#comment-16864142
]
Ignasi Barrera commented on JCLOUDS-1503:
-
https://github.com/apache/jclouds/pull/36
> Azurecompute-arm deploy doesn't work
>
>
> Key: JCLOUDS-1503
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1503
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.1.2
>Reporter: Simone
>Priority: Blocker
> Labels: azurecompute-arm, compute
> Attachments: Schermata del 2019-06-14 10-34-17.png, jclouds-wire.log,
> locations.json
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Deploying on azure/northeurope I have this error from this morning, I am
> passing northeurope as locationId
> Stacktrace:
> {noformat}
> java.lang.NumberFormatException: For input string: "54.39"
> at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
> at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:538)
> at com.google.gson.stream.JsonReader.nextDouble(JsonReader.java:925)
> at com.google.gson.Gson$3.read(Gson.java:268)
> at com.google.gson.Gson$3.read(Gson.java:262)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$ParameterReader.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.j$
> va:273)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflec$
> iveTypeAdapterFactory.java:185)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.readAndBuild(NullFilteringTypeAdapterFactories.java:95)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:83)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:62)
>
> at com.google.gson.Gson.fromJson(Gson.java:861)
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:80)
>
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:44)
>
> 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:84)
>
> at com.sun.proxy.$Proxy214.list(Unknown Source)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listLocations(AzureComputeServiceAdapter.java:307)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:84)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:81)
>
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTi$
> eOutButNotOnAuthorizationExceptionSupplier.java:75)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTim
> eOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3628)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2336)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2295)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2208)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4053)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4057)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4986)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.get(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:150)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.locationId(TemplateBuilderImpl.java:603)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (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:all-tabpanel
]
Ignasi Barrera reassigned JCLOUDS-1166:
---
Assignee: Ignasi Barrera
> 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: 10m
> 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)
[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=16863962#comment-16863962
]
Ignasi Barrera commented on JCLOUDS-1166:
-
Ok, I've already started it. It turns that shading and relocating the package
is much easier than just copying (to avoid checkstyle and error-prone conflicts
with the checks we currently have for jclouds).
Here it is: https://github.com/apache/jclouds/pull/35
> 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
>Priority: Major
> Labels: gson
> Time Spent: 10m
> 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)
[jira] [Commented] (JCLOUDS-1503) Azurecompute-arm deploy doesn't work
[
https://issues.apache.org/jira/browse/JCLOUDS-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863919#comment-16863919
]
Ignasi Barrera commented on JCLOUDS-1503:
-
Looks like a bug in the Azure API itself.
A quick fix would be to just remove those fields or convert them to String in
the jclouds model. I doubt anyone is actually using those fields, so I'm
confident that could be a pretty safe change. Thoughts?
> Azurecompute-arm deploy doesn't work
>
>
> Key: JCLOUDS-1503
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1503
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.1.2
>Reporter: Simone
>Priority: Blocker
> Labels: azurecompute-arm, compute
> Attachments: Schermata del 2019-06-14 10-34-17.png, locations.json
>
>
> Deploying on azure/northeurope I have this error from this morning, I am
> passing northeurope as locationId
> Stacktrace:
> {noformat}
> java.lang.NumberFormatException: For input string: "54.39"
> at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
> at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:538)
> at com.google.gson.stream.JsonReader.nextDouble(JsonReader.java:925)
> at com.google.gson.Gson$3.read(Gson.java:268)
> at com.google.gson.Gson$3.read(Gson.java:262)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$ParameterReader.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.j$
> va:273)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflec$
> iveTypeAdapterFactory.java:185)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.readAndBuild(NullFilteringTypeAdapterFactories.java:95)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:83)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:62)
>
> at com.google.gson.Gson.fromJson(Gson.java:861)
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:80)
>
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:44)
>
> 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:84)
>
> at com.sun.proxy.$Proxy214.list(Unknown Source)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listLocations(AzureComputeServiceAdapter.java:307)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:84)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:81)
>
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTi$
> eOutButNotOnAuthorizationExceptionSupplier.java:75)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTim
> eOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3628)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2336)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2295)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2208)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4053)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4057)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4986)
> at
[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=16863890#comment-16863890
]
Ignasi Barrera commented on JCLOUDS-1166:
-
I'll try to work on this next week, but if you want to have a look at it, it is
just about hunting the uses of the gson internal package in jclouds-core, copy
the clases that are actually used, and rename those internal packages to some
jclouds internal one. It shouldn't be a complicated task if you want to go for
it before I can do it.
> 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
>Priority: Major
> Labels: gson
>
> 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)
[jira] [Commented] (JCLOUDS-1503) Azurecompute-arm deploy doesn't work
[
https://issues.apache.org/jira/browse/JCLOUDS-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16863886#comment-16863886
]
Ignasi Barrera commented on JCLOUDS-1503:
-
Looks like something changed in Azure.
Can you attach the relevant [jclouds.wire
logs|https://jclouds.apache.org/reference/logging/] (removing any auth stuff
from them) so we can see the exact requests/responses?
> Azurecompute-arm deploy doesn't work
>
>
> Key: JCLOUDS-1503
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1503
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.1.2
>Reporter: Simone
>Priority: Blocker
> Labels: azurecompute-arm, compute
> Attachments: Schermata del 2019-06-14 10-34-17.png
>
>
> Deploying on azure/northeurope I have this error from this morning, I am
> passing northeurope as locationId
> Stacktrace:
> {noformat}
> java.lang.NumberFormatException: For input string: "54.39"
> at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
> at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
> at java.lang.Double.parseDouble(Double.java:538)
> at com.google.gson.stream.JsonReader.nextDouble(JsonReader.java:925)
> at com.google.gson.Gson$3.read(Gson.java:268)
> at com.google.gson.Gson$3.read(Gson.java:262)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$ParameterReader.read(DeserializationConstructorAndReflectiveTypeAdapterFactory.j$
> va:273)
> at
> org.jclouds.json.internal.DeserializationConstructorAndReflectiveTypeAdapterFactory$DeserializeIntoParameterizedConstructor.read(DeserializationConstructorAndReflec$
> iveTypeAdapterFactory.java:185)
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.readAndBuild(NullFilteringTypeAdapterFactories.java:95)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:83)
>
> at
> org.jclouds.json.internal.NullFilteringTypeAdapterFactories$IterableTypeAdapter.read(NullFilteringTypeAdapterFactories.java:62)
>
> at com.google.gson.Gson.fromJson(Gson.java:861)
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:80)
>
> at
> org.jclouds.http.functions.ParseFirstJsonValueNamed.apply(ParseFirstJsonValueNamed.java:44)
>
> 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:84)
>
> at com.sun.proxy.$Proxy214.list(Unknown Source)
> at
> org.jclouds.azurecompute.arm.compute.AzureComputeServiceAdapter.listLocations(AzureComputeServiceAdapter.java:307)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:84)
>
> at
> org.jclouds.compute.config.ComputeServiceAdapterContextModule$LocationsFromComputeServiceAdapterModule$1.get(ComputeServiceAdapterContextModule.java:81)
>
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTi$
> eOutButNotOnAuthorizationExceptionSupplier.java:75)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier$SetAndThrowAuthorizationExceptionSupplierBackedLoader.load(MemoizedRetryOnTim
> eOutButNotOnAuthorizationExceptionSupplier.java:57)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3628)
> at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2336)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2295)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2208)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4053)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4057)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4986)
> at
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButN
[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=16860068#comment-16860068
]
Ignasi Barrera commented on JCLOUDS-1166:
-
The move of karaf and cli to the Karaf community was not because of this issue.
Was for the inability for us to keep in sync with Karaf releases and being
unable to properly upgrade to newer ones.
I will implement this and copy the files. It is not a big deal. I mean, being
unable to upgrade the library and copying the bits you need it is pretty much
the same. Maintenance nightmare is not gonna be there as we need just a few
utility methods for reflection and some other small nits.
I plan to do this as soon as I can, but unfortunately I haven't had time to do
it yet.
There is no need to break OSGi and I think, given the relatively simple way we
have to keep it working, it's not worth it.
> 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
>Priority: Major
> Labels: gson
>
> 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)
[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=16841920#comment-16841920
]
Ignasi Barrera commented on JCLOUDS-1166:
-
Yes, we talked to the gson people: https://github.com/google/gson/pull/916
Ok, in the absence of more inputs I think we're going for the copying approach.
That allows us to progressively move away from the conflicting code while
keeping OSGi support. I don't see enough justification in dropping OSGi support
just to have a quick fix when we have simple workarounds too.
> 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
>Priority: Major
> Labels: gson
>
> 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)
Re: [jclouds/jclouds] Add ARM architecture to ec2 image and the related instance types (#1275)
Closed #1275. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1275#event-2339073250
Re: [jclouds/jclouds] Add ARM architecture to ec2 image and the related instance types (#1275)
Thanks! Merged to master and 2.1.x. For subsequent PRs please update your fork and submit them to https://github.com/apache/jclouds as we've moved there. Once the pending PRs in this one are merged this repo will be archived. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1275#issuecomment-492105314
[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=16839154#comment-16839154
]
Ignasi Barrera commented on JCLOUDS-1166:
-
[~oflebbe] [~andrewp] thoughts on my comment?
> 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
>Priority: Major
> Labels: gson
>
> 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)
[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=16836402#comment-16836402
]
Ignasi Barrera commented on JCLOUDS-1166:
-
[~jbonofre] would be great to have your thoughts on this discussion too.
> 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
>Priority: Major
> Labels: gson
>
> 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)
[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=16836400#comment-16836400
]
Ignasi Barrera commented on JCLOUDS-1166:
-
Yes, we could, but we get back to my pervious point: jclouds-karaf is no longer
owned by jclouds. It is now an Apache Karaf project. So, given that this is
*purely an OSGi issue*:
* If the fix we want is to just provide a custom bundle that ignores the
original package, that would probably live in jclouds-karaf and would have to
be maintained by the Karaf community. We can move ahead with the gson upgrade
issue right now if we make this call, and defer to the karaf community the
responsibility to keep up to date with this jclouds usage of OSGi-unexported
stuff. (Anyone that wants to use jclouds in karaf will have to use our bundle
and make sure there are no conflicts).
* If we really want to fix this in jclouds, we need to remove the usages of the
offending packages
** This change can be complex and sensitive, and I don't see us making it "in a
timely manner".
** Copying the offending classes to our project allows us to move forward and
upgrade nicely, have close to zero impact on users and ecosystem, and gives us
a clear and progressive deprecation and removal plan.
** As I see it, the main risk in copying stuff is diverging from upstream, but
we're just keeping it as a compatibility layer (since we're already upgrading
the dependency), and we really don't care about those bits being in sync with
upstream as we want to find an alternative way to do the same thing, or to trim
down the affected classes and extract just the behaviour we need.
Thoughts?
> 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
>Priority: Major
> Labels: gson
>
> 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)
[jira] [Updated] (JCLOUDS-1497) Fix jclouds-labs after JCLOUDS-1496
[
https://issues.apache.org/jira/browse/JCLOUDS-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1497:
Component/s: jclouds-core
> Fix jclouds-labs after JCLOUDS-1496
> ---
>
> Key: JCLOUDS-1497
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1497
> Project: jclouds
> Issue Type: Task
> Components: jclouds-core
>Reporter: Olaf Flebbe
>Priority: Major
> Fix For: 2.2.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See https://builds.apache.org/job/jclouds-labs/46/
> In order to reproduce run in jclouds-labs
> {code}
> mvn -DskipTests install -U -e -Psrc,doc,jenkins
> {code}
> checkstyle-suppressions.xml is not found in jclouds-labs. checkstyle.xml is
> found because it is included in jclouds-resources.jar. Adding
> checkstyle-suppressions to jclouds-resources did not work either:
> checkstyle-6.1.1 does load supressions from the class path, but IMO
> incorrectly (see
> https://github.com/checkstyle/checkstyle/blob/checkstyle-6.1.1/src/main/java/com/puppycrawl/tools/checkstyle/filters/SuppressionsLoader.java
> )
> {code}
> // check to see if the file is in the classpath
> try {
> final URL configUrl = SuppressionsLoader.class
> .getResource(aFilename);
> if (configUrl == null) {
> throw new FileNotFoundException(aFilename);
> }
> uri = configUrl.toURI();
> {code}
> This won't load stuff from jclouds-resources.jar on the classpath, but
> resources from checkstyle itself.
> Even using current checkstyle will not work, since this code has only been
> refactored but func-wise not altered.
> So we have only a limited number of options (beyond fixing checkstyle).
> # Add the file/dir resources/checkstyle-suppressions.xml to jclouds (having
> an ugly dependency)
> # Remove the check triggering the checkstyle problem.
> The check triggering the problem where we need the suppressions for, is the
> "header" module checking for the presence of the proper apache license header
> in each java file.
> May I suggest to remove the "header" check, since it is already covered by
> the apache-rat tool anyway? (Problem arises because some autogenerated
> transient code does not include the ASF license header.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (JCLOUDS-1497) Fix jclouds-labs after JCLOUDS-1496
[
https://issues.apache.org/jira/browse/JCLOUDS-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1497.
-
Resolution: Fixed
> Fix jclouds-labs after JCLOUDS-1496
> ---
>
> Key: JCLOUDS-1497
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1497
> Project: jclouds
> Issue Type: Task
> Components: jclouds-core
>Reporter: Olaf Flebbe
>Priority: Major
> Fix For: 2.2.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See https://builds.apache.org/job/jclouds-labs/46/
> In order to reproduce run in jclouds-labs
> {code}
> mvn -DskipTests install -U -e -Psrc,doc,jenkins
> {code}
> checkstyle-suppressions.xml is not found in jclouds-labs. checkstyle.xml is
> found because it is included in jclouds-resources.jar. Adding
> checkstyle-suppressions to jclouds-resources did not work either:
> checkstyle-6.1.1 does load supressions from the class path, but IMO
> incorrectly (see
> https://github.com/checkstyle/checkstyle/blob/checkstyle-6.1.1/src/main/java/com/puppycrawl/tools/checkstyle/filters/SuppressionsLoader.java
> )
> {code}
> // check to see if the file is in the classpath
> try {
> final URL configUrl = SuppressionsLoader.class
> .getResource(aFilename);
> if (configUrl == null) {
> throw new FileNotFoundException(aFilename);
> }
> uri = configUrl.toURI();
> {code}
> This won't load stuff from jclouds-resources.jar on the classpath, but
> resources from checkstyle itself.
> Even using current checkstyle will not work, since this code has only been
> refactored but func-wise not altered.
> So we have only a limited number of options (beyond fixing checkstyle).
> # Add the file/dir resources/checkstyle-suppressions.xml to jclouds (having
> an ugly dependency)
> # Remove the check triggering the checkstyle problem.
> The check triggering the problem where we need the suppressions for, is the
> "header" module checking for the presence of the proper apache license header
> in each java file.
> May I suggest to remove the "header" check, since it is already covered by
> the apache-rat tool anyway? (Problem arises because some autogenerated
> transient code does not include the ASF license header.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1497) Fix jclouds-labs after JCLOUDS-1496
[
https://issues.apache.org/jira/browse/JCLOUDS-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1497:
Fix Version/s: 2.2.0
> Fix jclouds-labs after JCLOUDS-1496
> ---
>
> Key: JCLOUDS-1497
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1497
> Project: jclouds
> Issue Type: Task
>Reporter: Olaf Flebbe
>Priority: Major
> Fix For: 2.2.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See https://builds.apache.org/job/jclouds-labs/46/
> In order to reproduce run in jclouds-labs
> {code}
> mvn -DskipTests install -U -e -Psrc,doc,jenkins
> {code}
> checkstyle-suppressions.xml is not found in jclouds-labs. checkstyle.xml is
> found because it is included in jclouds-resources.jar. Adding
> checkstyle-suppressions to jclouds-resources did not work either:
> checkstyle-6.1.1 does load supressions from the class path, but IMO
> incorrectly (see
> https://github.com/checkstyle/checkstyle/blob/checkstyle-6.1.1/src/main/java/com/puppycrawl/tools/checkstyle/filters/SuppressionsLoader.java
> )
> {code}
> // check to see if the file is in the classpath
> try {
> final URL configUrl = SuppressionsLoader.class
> .getResource(aFilename);
> if (configUrl == null) {
> throw new FileNotFoundException(aFilename);
> }
> uri = configUrl.toURI();
> {code}
> This won't load stuff from jclouds-resources.jar on the classpath, but
> resources from checkstyle itself.
> Even using current checkstyle will not work, since this code has only been
> refactored but func-wise not altered.
> So we have only a limited number of options (beyond fixing checkstyle).
> # Add the file/dir resources/checkstyle-suppressions.xml to jclouds (having
> an ugly dependency)
> # Remove the check triggering the checkstyle problem.
> The check triggering the problem where we need the suppressions for, is the
> "header" module checking for the presence of the proper apache license header
> in each java file.
> May I suggest to remove the "header" check, since it is already covered by
> the apache-rat tool anyway? (Problem arises because some autogenerated
> transient code does not include the ASF license header.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1496) Update maven-compiler-plugin for increased JDK compatibility
[ https://issues.apache.org/jira/browse/JCLOUDS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1496: Component/s: jclouds-core > Update maven-compiler-plugin for increased JDK compatibility > - > > Key: JCLOUDS-1496 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1496 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Reporter: Olaf Flebbe >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > The maven-compiler-plugin is referenced in the wrong clause of the pom file. > It should be within . > (See for instance > https://maven.apache.org/plugins/maven-compiler-plugin/usage.html ) > Otherwise you will see Nullptr Exceptions for instance with JDK11. > For now I propose to only move the plugin and use current version 3.8.0. > Increasing the errorprone module version will trigger a lot of diagnostics in > errorprone plugins, which should be dealt seperately. > Doublechecked: Still compiles with java 1.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JCLOUDS-1496) Update maven-compiler-plugin for increased JDK compatibility
[ https://issues.apache.org/jira/browse/JCLOUDS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1496. - Resolution: Fixed > Update maven-compiler-plugin for increased JDK compatibility > - > > Key: JCLOUDS-1496 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1496 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Reporter: Olaf Flebbe >Priority: Major > Fix For: 2.2.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > The maven-compiler-plugin is referenced in the wrong clause of the pom file. > It should be within . > (See for instance > https://maven.apache.org/plugins/maven-compiler-plugin/usage.html ) > Otherwise you will see Nullptr Exceptions for instance with JDK11. > For now I propose to only move the plugin and use current version 3.8.0. > Increasing the errorprone module version will trigger a lot of diagnostics in > errorprone plugins, which should be dealt seperately. > Doublechecked: Still compiles with java 1.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1496) Update maven-compiler-plugin for increased JDK compatibility
[ https://issues.apache.org/jira/browse/JCLOUDS-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1496: Fix Version/s: 2.2.0 > Update maven-compiler-plugin for increased JDK compatibility > - > > Key: JCLOUDS-1496 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1496 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Reporter: Olaf Flebbe >Priority: Major > Fix For: 2.2.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > The maven-compiler-plugin is referenced in the wrong clause of the pom file. > It should be within . > (See for instance > https://maven.apache.org/plugins/maven-compiler-plugin/usage.html ) > Otherwise you will see Nullptr Exceptions for instance with JDK11. > For now I propose to only move the plugin and use current version 3.8.0. > Increasing the errorprone module version will trigger a lot of diagnostics in > errorprone plugins, which should be dealt seperately. > Doublechecked: Still compiles with java 1.8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (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=16834504#comment-16834504
]
Ignasi Barrera edited comment on JCLOUDS-1166 at 5/7/19 8:33 AM:
-
The main issue here is that simply upgrading will break jclouds in OSGi, as the
classes we use in the {{internal}} packages won't be available there.
So, we have to make the call for the fix:
* Now jclouds-karaf and jclouds-cli will be managed by the Apache Karaf
community:
** If we go for the custom bundle approach (probably something that could land
in ServiceMix), should the Karaf team take care of it?
** If not, where should we host/maintain that bundle?
* If we are going to the copy approach, then we should copy the relevant
classes and work towards refactoring the code so we don't need that stuff.
[~andrewp], [~gaul], [~jbonofre] thoughts?
was (Author: nacx):
The main issue here is that simply upgrading will break jclouds in OSGi, as the
classes we use in the {{internal}} packages won't be available there.
So, we have to make the call for the fix:
* Now jclouds-karaf and jclouds-cli will be managed by the Apache Karaf
community:
** If we go for the custom bundle approach (probably something that could land
in ServiceMix), should the Karaf team take care of it?
** If not, where should we host/maintain that bundle?
* If we are going to the copy approach, then we should copy the relevant
classes and work towards refacotring the code so we don't need that stuff.
[~andrewp], [~gaul], [~jbonofre] thoughts?
> 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
>Priority: Major
> Labels: gson
>
> 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)
[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=16834504#comment-16834504
]
Ignasi Barrera commented on JCLOUDS-1166:
-
The main issue here is that simply upgrading will break jclouds in OSGi, as the
classes we use in the {{internal}} packages won't be available there.
So, we have to make the call for the fix:
* Now jclouds-karaf and jclouds-cli will be managed by the Apache Karaf
community:
** If we go for the custom bundle approach (probably something that could land
in ServiceMix), should the Karaf team take care of it?
** If not, where should we host/maintain that bundle?
* If we are going to the copy approach, then we should copy the relevant
classes and work towards refacotring the code so we don't need that stuff.
[~andrewp], [~gaul], [~jbonofre] thoughts?
> 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
>Priority: Major
> Labels: gson
>
> 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)
[jira] [Updated] (JCLOUDS-1499) Disable sonatype snapshot repository for plugins
[ https://issues.apache.org/jira/browse/JCLOUDS-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1499: Fix Version/s: 2.2.0 > Disable sonatype snapshot repository for plugins > > > Key: JCLOUDS-1499 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1499 > Project: jclouds > Issue Type: Task >Affects Versions: 2.2.0 >Reporter: Olaf Flebbe >Priority: Major > Fix For: 2.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > As far as I can see, the ossrh repository > (https://oss.sonatype.org/content/repositories/snapshots) > is not needed. > It slows down compilation considerably. > Lets remove the maven repository from the pom -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1499) Disable sonatype snapshot repository for plugins
[ https://issues.apache.org/jira/browse/JCLOUDS-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1499: Component/s: jclouds-core > Disable sonatype snapshot repository for plugins > > > Key: JCLOUDS-1499 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1499 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Affects Versions: 2.2.0 >Reporter: Olaf Flebbe >Priority: Major > Fix For: 2.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > As far as I can see, the ossrh repository > (https://oss.sonatype.org/content/repositories/snapshots) > is not needed. > It slows down compilation considerably. > Lets remove the maven repository from the pom -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1499) Disable sonatype snapshot repository for plugins
[ https://issues.apache.org/jira/browse/JCLOUDS-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1499: Affects Version/s: 2.2.0 > Disable sonatype snapshot repository for plugins > > > Key: JCLOUDS-1499 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1499 > Project: jclouds > Issue Type: Task >Affects Versions: 2.2.0 >Reporter: Olaf Flebbe >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > As far as I can see, the ossrh repository > (https://oss.sonatype.org/content/repositories/snapshots) > is not needed. > It slows down compilation considerably. > Lets remove the maven repository from the pom -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JCLOUDS-1499) Disable sonatype snapshot repository for plugins
[ https://issues.apache.org/jira/browse/JCLOUDS-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1499. - Resolution: Fixed > Disable sonatype snapshot repository for plugins > > > Key: JCLOUDS-1499 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1499 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Affects Versions: 2.2.0 >Reporter: Olaf Flebbe >Priority: Major > Fix For: 2.2.0 > > Time Spent: 20m > Remaining Estimate: 0h > > As far as I can see, the ossrh repository > (https://oss.sonatype.org/content/repositories/snapshots) > is not needed. > It slows down compilation considerably. > Lets remove the maven repository from the pom -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [jclouds/jclouds] JCLOUDS-847: Poor upload performance for putBlob (#1274)
nacx commented on this pull request. LGTM We have migrated to the Apache GitHub org. Mind closing this PR and reopening again here? https://github.com/apache/jclouds > @@ -325,7 +325,14 @@ * */ public static final String PROPERTY_TIMEOUTS_PREFIX = "jclouds.timeouts."; - + + /** +* Integer property. Default (32768). +* +* Buffer size for socket write. Explain here that this is only considered int he default java http driver -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/1274#pullrequestreview-230145896
[jira] [Resolved] (JCLOUDS-1495) maven plugins are not correctly referred to
[ https://issues.apache.org/jira/browse/JCLOUDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera resolved JCLOUDS-1495. - Resolution: Fixed > maven plugins are not correctly referred to > --- > > Key: JCLOUDS-1495 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1495 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Affects Versions: 2.1.2 >Reporter: Olaf Flebbe >Priority: Major > Fix For: 2.2.0, 2.1.3 > > Attachments: > 0001-JCLOUDS-1495-maven-plugins-are-not-correctly-referre.patch > > Time Spent: 40m > Remaining Estimate: 0h > > While trying to upgrade maven plugins to a current level, some of my attempts > didn't work because the tag for some maven standard plugins are > missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1495) maven plugins are not correctly referred to
[ https://issues.apache.org/jira/browse/JCLOUDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1495: Component/s: jclouds-core > maven plugins are not correctly referred to > --- > > Key: JCLOUDS-1495 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1495 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Affects Versions: 2.1.2 >Reporter: Olaf Flebbe >Priority: Major > Attachments: > 0001-JCLOUDS-1495-maven-plugins-are-not-correctly-referre.patch > > Time Spent: 40m > Remaining Estimate: 0h > > While trying to upgrade maven plugins to a current level, some of my attempts > didn't work because the tag for some maven standard plugins are > missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1495) maven plugins are not correctly referred to
[ https://issues.apache.org/jira/browse/JCLOUDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1495: Fix Version/s: 2.1.3 2.2.0 > maven plugins are not correctly referred to > --- > > Key: JCLOUDS-1495 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1495 > Project: jclouds > Issue Type: Task > Components: jclouds-core >Affects Versions: 2.1.2 >Reporter: Olaf Flebbe >Priority: Major > Fix For: 2.2.0, 2.1.3 > > Attachments: > 0001-JCLOUDS-1495-maven-plugins-are-not-correctly-referre.patch > > Time Spent: 40m > Remaining Estimate: 0h > > While trying to upgrade maven plugins to a current level, some of my attempts > didn't work because the tag for some maven standard plugins are > missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (JCLOUDS-1495) maven plugins are not correctly referred to
[ https://issues.apache.org/jira/browse/JCLOUDS-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignasi Barrera updated JCLOUDS-1495: Affects Version/s: 2.1.2 > maven plugins are not correctly referred to > --- > > Key: JCLOUDS-1495 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1495 > Project: jclouds > Issue Type: Task >Affects Versions: 2.1.2 >Reporter: Olaf Flebbe >Priority: Major > Attachments: > 0001-JCLOUDS-1495-maven-plugins-are-not-correctly-referre.patch > > Time Spent: 40m > Remaining Estimate: 0h > > While trying to upgrade maven plugins to a current level, some of my attempts > didn't work because the tag for some maven standard plugins are > missing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JCLOUDS-1492) Dimension Data Feature API Predicates are not usable
[
https://issues.apache.org/jira/browse/JCLOUDS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera resolved JCLOUDS-1492.
-
Resolution: Fixed
Fix Version/s: 2.1.3
2.2.0
> Dimension Data Feature API Predicates are not usable
>
>
> Key: JCLOUDS-1492
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1492
> Project: jclouds
> Issue Type: Bug
>Reporter: Trevor Flanagan
>Priority: Major
> Labels: dimensiondata
> Fix For: 2.2.0, 2.1.3
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The predicates exposed in
> [https://github.com/apache/jclouds-labs/blob/master/dimensiondata/src/main/java/org/jclouds/dimensiondata/cloudcontrol/features/ServerApi.java#L183-L197]
> and other Feature API are not working as expected.
> The issue is that where an interface is marked with {{@Delegate}} anything
> that exists inside is considered as something that will be invoked over HTTP.
> In the case of the Predicates these are not the case. The following error
> occurs when a call to
> {{api.getNetworkApi().networkDomainNormalPredicate().apply(networkDomainId);}}
> is made.
> {code:java}
> Exception in thread "main" java.lang.IllegalStateException: Optional.get()
> cannot be called on an absent value
> at com.google.common.base.Absent.get(Absent.java:47)
> at
> org.jclouds.rest.internal.RestAnnotationProcessor.apply(RestAnnotationProcessor.java:227)
> at
> org.jclouds.rest.internal.RestAnnotationProcessor.apply(RestAnnotationProcessor.java:137)
> at
> org.jclouds.rest.internal.InvokeHttpMethod.toCommand(InvokeHttpMethod.java:189)
> at org.jclouds.rest.internal.InvokeHttpMethod.invoke(InvokeHttpMethod.java:85)
> 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 com.sun.proxy.$Proxy56.networkDomainNormalPredicate(Unknown Source)
> at
> org.jclouds.examples.dimensiondata.cloudcontrol.DeployNetworkDomainVlanAndServer.deployNetworkDomain(DeployNetworkDomainVlanAndServer.java:148)
> at
> org.jclouds.examples.dimensiondata.cloudcontrol.DeployNetworkDomainVlanAndServer.main(DeployNetworkDomainVlanAndServer.java:78){code}
> The fix is to move the Predicates into
> {{org.jclouds.dimensiondata.cloudcontrol.DimensionDataCloudControlApi}} and
> remove them from the API classes.
> {code:java}
> public interface DimensionDataCloudControlApi extends Closeable {
>@Delegate
>AccountApi getAccountApi();
>@Delegate
>InfrastructureApi getInfrastructureApi();
>@Delegate
>ServerImageApi getServerImageApi();
>@Delegate
>NetworkApi getNetworkApi();
>@Delegate
>ServerApi getServerApi();
>@Delegate
>TagApi getTagApi();
>@Delegate
>CustomerImageApi getCustomerImageApi();
>@Provides
>@Named(VLAN_DELETED_PREDICATE)
>Predicate vlanDeletedPredicate();
>@Provides
>@Named(NETWORK_DOMAIN_DELETED_PREDICATE)
>Predicate networkDomainDeletedPredicate();
>@Provides
>@Named(NETWORK_DOMAIN_NORMAL_PREDICATE)
>Predicate networkDomainNormalPredicate();
>@Provides
>@Named(VLAN_NORMAL_PREDICATE)
>Predicate vlanNormalPredicate();
>@Provides
>@Named(SERVER_STOPPED_PREDICATE)
>Predicate serverStoppedPredicate();
>@Provides
>@Named(SERVER_DELETED_PREDICATE)
>Predicate serverDeletedPredicate();
>@Provides
>@Named(SERVER_STARTED_PREDICATE)
>Predicate serverStartedPredicate();
>@Provides
>@Named(SERVER_NORMAL_PREDICATE)
>Predicate serverNormalPredicate();
> }
> {code}
> Fix also requires a change to the
> https://github.com/apache/jclouds-examples/tree/master/dimensiondata
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (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=16806226#comment-16806226
]
Ignasi Barrera edited comment on JCLOUDS-1428 at 3/31/19 6:15 PM:
--
It is called
[here|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/functions/BlobPropertiesToBlobMetadata.java#L58].
That {{BlobPropertiesToBlobMetadata}} function is called everytime a blob is
retrieved using the {{AzureBlobStore}}. If you look at the usages of [these
two|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/AzureBlobStore.java#L93-L94]
variables and [this
one|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/AzureBlobStore.java#L96],
you'll see when that gets called, which is basically when getting a blob, or
getting a list of blobs, so, in practice, it will always fail for SAS tokens,
I wonder if it would make sense to disable getting that info when we already
know it can't be retrieved with the provided credentials? [~gaul] WDYT?
was (Author: nacx):
It is called
[here|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/functions/BlobPropertiesToBlobMetadata.java#L58].
That {{BlobPropertiesToBlobMetadata}} function is called everytime a blob is
retrieved using the {{AzureBlobStore}}. If you look at the usages of [these
two|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/AzureBlobStore.java#L93-L94]
variables and [this
one|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/AzureBlobStore.java#L96],
you'll see when that gets called, which is basically when getting a blob, or
getting a list of blobs, so, in practice, it will always fail for SAS tokens,
I wonder if it would make sense to disable getting that info when we already
know it can't be retrieved with the provided credntials? [~gaul] WDYT?
> 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
>Priority: Major
> Labels: azureblob
> Fix For: 2.2.0, 2.1.3
>
> Attachments: azure_stacktrace.txt
>
> Time Spent: 40m
> 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
(v7.6.3#76005)
[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=16806226#comment-16806226
]
Ignasi Barrera commented on JCLOUDS-1428:
-
It is called
[here|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/functions/BlobPropertiesToBlobMetadata.java#L58].
That {{BlobPropertiesToBlobMetadata}} function is called everytime a blob is
retrieved using the {{AzureBlobStore}}. If you look at the usages of [these
two|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/AzureBlobStore.java#L93-L94]
variables and [this
one|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/blobstore/AzureBlobStore.java#L96],
you'll see when that gets called, which is basically when getting a blob, or
getting a list of blobs, so, in practice, it will always fail for SAS tokens,
I wonder if it would make sense to disable getting that info when we already
know it can't be retrieved with the provided credntials? [~gaul] WDYT?
> 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
>Priority: Major
> Labels: azureblob
> Fix For: 2.2.0, 2.1.3
>
> Attachments: azure_stacktrace.txt
>
> Time Spent: 40m
> 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
(v7.6.3#76005)
