[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.Iterator iterator()>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
> (com.google.common.io.ByteSource,org.jclouds.io.ContentMetadata)>
> Repositories\org\apache\jclouds\jclouds-core\2.3.0-SNAPSHOT\jclouds-core-2.3.0-SNAPSHOT.jar
>
[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=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',
>
[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)
[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) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024) > at > com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(InternalInjectorCreator.java:198) > at >
[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
> org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(BaseComputeService.java:225)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 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=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 > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024) > at > com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(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.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:65)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
> at
>
[jira] [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.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
>
[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.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:204)
> at
> com.google.inject.internal.InternalInjectorCreator$1.call(InternalInjectorCreator.java:198)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)
> 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=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.InternalInjectorCreator$1.call(InternalInjectorCreator.java:198) > at > com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024) > at > com.google.inject.internal.InternalInjectorCreator.loadEagerSingletons(InternalInjectorCreator.java:198) > at >
[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.arm.publishers" to an empty string breaks line: 666
> (:p) in TemplateBuilderImpl
> "checkState(!images.isEmpty(), "no images present!");"
> Can I make a PR to change that line, to explode when images are empty but
> only when no
[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(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.arm.publishers" to
[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
> request -1332190413: GET
> https://roded-data.s3-eu-central-1.amazonaws.com/blobname HTTP/1.1
> 2019-10-10 18:15:21.517 FINEST [sun.net.www.protocol.http.HttpURLConnection
> ] Looking for HttpClient for URL
> https://roded-data.s3-eu-central-1.amazonaws.com/blobname and proxy value of
> DIRECT
> 2019-10-10 18:15:21.519 FINEST [sun.net.www.protocol.http.HttpURLConnection
> ] Creating new
[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"?>[\n]" > 17:22:25.673 [bscThread-02] DEBUG jclouds.wire - << > "BucketAlreadyOwnedByYouYour previous request to > create the named bucket succeeded and you already own > it.test309E5163C51F25F34WuN84GYMs47Nn6+48XYDpLZNvp0NPszokKyhxlzZk+ub8RhjbLpkfEI8E2tKWVCFKtJiXrhdpkc=" > 17:22:25.680 [bscThread-03] DEBUG o.j.rest.internal.InvokeHttpMethod - >> > invoking BucketExists > 17:22:25.681 [bscThread-03] DEBUG
[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 ]
> >> invoking GetObject
> 2019-10-10 18:15:21.514 FINE
> [org.jclouds.http.internal.JavaUrlHttpCommandExecutorService ] Sending
> request -1332190413: GET
> https://roded-data.s3-eu-central-1.amazonaws.com/blobname HTTP/1.1
> 2019-10-10 18:15:21.517 FINEST [sun.net.www.protocol.http.HttpURLConnection
> ] Looking for HttpClient for URL
>
[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-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-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 ]
> >> invoking GetObject
> 2019-10-10 18:15:21.514 FINE
> [org.jclouds.http.internal.JavaUrlHttpCommandExecutorService ] Sending
> request -1332190413: GET
> https://roded-data.s3-eu-central-1.amazonaws.com/blobname HTTP/1.1
> 2019-10-10 18:15:21.517 FINEST [sun.net.www.protocol.http.HttpURLConnection
> ] Looking for HttpClient for URL
>
[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 18:15:21.500 FINE[org.jclouds.rest.internal.InvokeHttpMethod ]
> >> invoking GetObject
> 2019-10-10 18:15:21.514 FINE
> [org.jclouds.http.internal.JavaUrlHttpCommandExecutorService ] Sending
> request -1332190413: GET
> https://roded-data.s3-eu-central-1.amazonaws.com/blobname HTTP/1.1
> 2019-10-10 18:15:21.517 FINEST [sun.net.www.protocol.http.HttpURLConnection
> ]
[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.google.gson.Gson.fromJson(Gson.java:861) at
> com.google.gson.Gson.fromJson(Gson.java:826) at
> org.jclouds.json.internal.GsonWrapper.fromJson(GsonWrapper.java:55) at
> org.jclouds.http.functions.ParseJson.apply(ParseJson.java:82)
[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)
[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)
[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
> org.jclouds.rest.suppliers.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.get(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:150)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.locationId(TemplateBuilderImpl.java:603)
>
[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.MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.get(MemoizedRetryOnTimeOutButNotOnAuthorizationExceptionSupplier.java:150)
> at
> org.jclouds.compute.domain.internal.TemplateBuilderImpl.locationId(TemplateBuilderImpl.java:603)
> {noformat}
--
This message was sent by Atlassian JIRA
[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)
[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)
[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)
[jira] [Commented] (JCLOUDS-693) Support OpenStack Orchestration (Heat) API
[
https://issues.apache.org/jira/browse/JCLOUDS-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795789#comment-16795789
]
Ignasi Barrera commented on JCLOUDS-693:
That looks good. Since the parameter is optional, though, you should mark the
getter method as {{@Nullable}} too, and do the same with the create method
parameter. Change to {{@Nullable Boolean existing}} (note the object, not the
primitive type to allow a {{null}} value there.
You should also update the {{StackApiMockTest}} and include a test that sends
the new parameter to make sure the request is generated as expected.
Feel free to open a pull request to this repo
https://github.com/apache/jclouds-labs-openstack and continue the discussion
there
> Support OpenStack Orchestration (Heat) API
> --
>
> Key: JCLOUDS-693
> URL: https://issues.apache.org/jira/browse/JCLOUDS-693
> Project: jclouds
> Issue Type: New Feature
> Components: jclouds-labs-openstack
>Reporter: Jeremy Daggett
>Priority: Major
> Labels: openstack, orchestration
>
> Heat is the main project in the OpenStack Orchestration program. It
> implements an orchestration engine to launch multiple composite cloud
> applications based on templates in the form of text files that can be treated
> like code. A native Heat template format is evolving, but Heat also
> endeavours to provide compatibility with the AWS CloudFormation template
> format, so that many existing CloudFormation templates can be launched on
> OpenStack. Heat provides both an OpenStack-native ReST API and a
> CloudFormation-compatible Query API.
> API Docs: http://developer.openstack.org/api-ref-orchestration-v1.html
> OpenStack Heat Wiki: https://wiki.openstack.org/wiki/Heat
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-693) Support OpenStack Orchestration (Heat) API
[ https://issues.apache.org/jira/browse/JCLOUDS-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16795775#comment-16795775 ] Ignasi Barrera commented on JCLOUDS-693: Do you want to ty add it yourself and open a pull request? We'll be happy to provide help and guidance. > Support OpenStack Orchestration (Heat) API > -- > > Key: JCLOUDS-693 > URL: https://issues.apache.org/jira/browse/JCLOUDS-693 > Project: jclouds > Issue Type: New Feature > Components: jclouds-labs-openstack >Reporter: Jeremy Daggett >Priority: Major > Labels: openstack, orchestration > > Heat is the main project in the OpenStack Orchestration program. It > implements an orchestration engine to launch multiple composite cloud > applications based on templates in the form of text files that can be treated > like code. A native Heat template format is evolving, but Heat also > endeavours to provide compatibility with the AWS CloudFormation template > format, so that many existing CloudFormation templates can be launched on > OpenStack. Heat provides both an OpenStack-native ReST API and a > CloudFormation-compatible Query API. > API Docs: http://developer.openstack.org/api-ref-orchestration-v1.html > OpenStack Heat Wiki: https://wiki.openstack.org/wiki/Heat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (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:all-tabpanel ] Ignasi Barrera reopened JCLOUDS-1428: - Thanks [~swatijain1101] for the detailed feedback. We'll get that fixed. > 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 > > > 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=16789344#comment-16789344 ] Ignasi Barrera commented on JCLOUDS-1428: - If the case is the one [~Horuszko] described, then here are two data points: * The code that checks if the provided credentials are a SAS token is [this one|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/main/java/org/jclouds/azureblob/config/AzureBlobHttpApiModule.java#L76-L91] * Here are [the tests|https://github.com/apache/jclouds/blob/master/providers/azureblob/src/test/java/org/jclouds/azureblob/config/AzureBlobHttpApiModuleTest.java] that validate this behavior. [~roy.biswa] could you verify if the check is accurate and matches the layout of your SAS token? If not, could you give us the details (the ones you can without exposing your credentials) about the format of your token, so we can add it to the test suite and fix the credential check method? > 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 > > > 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=16789336#comment-16789336 ] Ignasi Barrera commented on JCLOUDS-1428: - Please, don't do that. Keep the discussion here so others can also benefit from it. > 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 > > > 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=16789328#comment-16789328 ] Ignasi Barrera commented on JCLOUDS-1428: - Looks like the stacktrace is not attached. Could you attach it? > 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 > > > 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-1490) Azure destroyNode try to delete a NIC in use
[
https://issues.apache.org/jira/browse/JCLOUDS-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783836#comment-16783836
]
Ignasi Barrera commented on JCLOUDS-1490:
-
Can you provide the complete stacktrace for the exception?
> Azure destroyNode try to delete a NIC in use
> -
>
> Key: JCLOUDS-1490
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1490
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.1.2
>Reporter: Simone
>Priority: Trivial
> Labels: azurecompute-arm
>
> I had this error once undeploying a VM on Azure:
> {noformat}
> IllegalArgumentException: {
> "error": {
> "code": "NicInUse",
> "message": "Network Interface
> /subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/networkInterfaces/jclouds-XXX
> is used by existing resource
> /subscriptions/XXX/XXX/providers/Microsoft.Compute/virtualMachines/XXX.",
> "details": []
> }
> }
> {noformat}
> Looks like the machine was not yet undeployed.
> The stacktrace points to
> {noformat}
> computeService.destroyNode( instanceId );
> {noformat}
> And it is probably related to:
> {noformat}
> CleanupResources -> public boolean cleanupVirtualMachineNICs(VirtualMachine
> virtualMachine)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1426) Jclouds does not return all private ip address of aws ec2 instance
[
https://issues.apache.org/jira/browse/JCLOUDS-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16768116#comment-16768116
]
Ignasi Barrera commented on JCLOUDS-1426:
-
Yes. The {{RunningInstance}} object as returned by the AWS API does not provide
the complete list of addresses, so at the point I linked there are additional
API calls to be made to fetch the additional NICs the instance may have and get
their IP addresses. We'd be happy to provide guidance in the jclouds dev
mailing list or in the slack channel.
> Jclouds does not return all private ip address of aws ec2 instance
> --
>
> Key: JCLOUDS-1426
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1426
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.0.3
> Environment: AWS EC2
>Reporter: Dushyant Gupta
>Assignee: Andrea Turli
>Priority: Major
>
> I have made use of apache jclouds library to fetch ec2 instance details. I
> have attached 2 network interfaces on a single ec2 instance to provide it 2
> IPs.
> [!https://i.stack.imgur.com/xSHU3.png!|https://i.stack.imgur.com/xSHU3.png]
> But from the following code of jclouds, I see only one IP (of primary
> interface [eth0]) getting retrieved.
> {{ ComputeService cs = computeContext.getComputeService(); }}
> {{ for (ComputeMetadata cm : cs.listNodes()){ }}
> {{ NodeMetadata nm = (NodeMetadata) cm; }}
> {{ System.out.println(nm); }}
> {{ }}}
>
> In the output I can see only one IP address:
> {quote}privateAddresses=[172.26.119.234]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCLOUDS-1426) Jclouds does not return all private ip address of aws ec2 instance
[
https://issues.apache.org/jira/browse/JCLOUDS-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16767043#comment-16767043
]
Ignasi Barrera edited comment on JCLOUDS-1426 at 2/13/19 10:50 AM:
---
As [~andreaturli] said, currently jclouds reads the {{ipAddress}} and
{{privateIpAddress}} fields of the
[RunningInstence|https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html]
type to populate the ips of the node (See
[here|https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/compute/functions/RunningInstanceToNodeMetadata.java#L116-L119].
To fix this, instead, jclouds should be calling the AWS API to get all the NICs
attached to the instance and get those IPs.
If no one has still stepped in to fix this, is probably due to lack of cycles
to spend on this. If you were willing to give it a try, we would be more than
happy to provide help and guidance so you can contribute the fix.
was (Author: nacx):
As [~andreaturli] said, currently jclouds reads the {{ipAddress}} and
{{privateIpAddress}} fields of the
[RunningInstence|https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html]
type to populate the ips of the node (See
[here|https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/compute/functions/RunningInstanceToNodeMetadata.java#L116-L119}.
To fix this, instead, jclouds should be calling the AWS API to get all the NICs
attached to the instance and get those IPs.
If no one has still stepped in to fix this, is probably due to lack of cycles
to spend on this. If you were willing to give it a try, we would be more than
happy to provide help and guidance so you can contribute the fix.
> Jclouds does not return all private ip address of aws ec2 instance
> --
>
> Key: JCLOUDS-1426
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1426
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.0.3
> Environment: AWS EC2
>Reporter: Dushyant Gupta
>Assignee: Andrea Turli
>Priority: Major
>
> I have made use of apache jclouds library to fetch ec2 instance details. I
> have attached 2 network interfaces on a single ec2 instance to provide it 2
> IPs.
> [!https://i.stack.imgur.com/xSHU3.png!|https://i.stack.imgur.com/xSHU3.png]
> But from the following code of jclouds, I see only one IP (of primary
> interface [eth0]) getting retrieved.
> {{ ComputeService cs = computeContext.getComputeService(); }}
> {{ for (ComputeMetadata cm : cs.listNodes()){ }}
> {{ NodeMetadata nm = (NodeMetadata) cm; }}
> {{ System.out.println(nm); }}
> {{ }}}
>
> In the output I can see only one IP address:
> {quote}privateAddresses=[172.26.119.234]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCLOUDS-1426) Jclouds does not return all private ip address of aws ec2 instance
[
https://issues.apache.org/jira/browse/JCLOUDS-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16767043#comment-16767043
]
Ignasi Barrera commented on JCLOUDS-1426:
-
As [~andreaturli] said, currently jclouds reads the {{ipAddress}} and
{{privateIpAddress}} fields of the
[RunningInstence|https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html]
type to populate the ips of the node (See
[here|https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/compute/functions/RunningInstanceToNodeMetadata.java#L116-L119}.
To fix this, instead, jclouds should be calling the AWS API to get all the NICs
attached to the instance and get those IPs.
If no one has still stepped in to fix this, is probably due to lack of cycles
to spend on this. If you were willing to give it a try, we would be more than
happy to provide help and guidance so you can contribute the fix.
> Jclouds does not return all private ip address of aws ec2 instance
> --
>
> Key: JCLOUDS-1426
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1426
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.0.3
> Environment: AWS EC2
>Reporter: Dushyant Gupta
>Assignee: Andrea Turli
>Priority: Major
>
> I have made use of apache jclouds library to fetch ec2 instance details. I
> have attached 2 network interfaces on a single ec2 instance to provide it 2
> IPs.
> [!https://i.stack.imgur.com/xSHU3.png!|https://i.stack.imgur.com/xSHU3.png]
> But from the following code of jclouds, I see only one IP (of primary
> interface [eth0]) getting retrieved.
> {{ ComputeService cs = computeContext.getComputeService(); }}
> {{ for (ComputeMetadata cm : cs.listNodes()){ }}
> {{ NodeMetadata nm = (NodeMetadata) cm; }}
> {{ System.out.println(nm); }}
> {{ }}}
>
> In the output I can see only one IP address:
> {quote}privateAddresses=[172.26.119.234]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCLOUDS-1426) Jclouds does not return all private ip address of aws ec2 instance
[
https://issues.apache.org/jira/browse/JCLOUDS-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16767043#comment-16767043
]
Ignasi Barrera edited comment on JCLOUDS-1426 at 2/13/19 10:51 AM:
---
As [~andreaturli] said, currently jclouds reads the {{ipAddress}} and
{{privateIpAddress}} fields of the
[RunningInstence|https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html]
type to populate the ips of the node (See
[here|https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/compute/functions/RunningInstanceToNodeMetadata.java#L116-L119]).
To fix this, instead, jclouds should be calling the AWS API to get all the NICs
attached to the instance and get those IPs.
If no one has still stepped in to fix this, is probably due to lack of cycles
to spend on this. If you were willing to give it a try, we would be more than
happy to provide help and guidance so you can contribute the fix.
was (Author: nacx):
As [~andreaturli] said, currently jclouds reads the {{ipAddress}} and
{{privateIpAddress}} fields of the
[RunningInstence|https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Instance.html]
type to populate the ips of the node (See
[here|https://github.com/jclouds/jclouds/blob/master/apis/ec2/src/main/java/org/jclouds/ec2/compute/functions/RunningInstanceToNodeMetadata.java#L116-L119].
To fix this, instead, jclouds should be calling the AWS API to get all the NICs
attached to the instance and get those IPs.
If no one has still stepped in to fix this, is probably due to lack of cycles
to spend on this. If you were willing to give it a try, we would be more than
happy to provide help and guidance so you can contribute the fix.
> Jclouds does not return all private ip address of aws ec2 instance
> --
>
> Key: JCLOUDS-1426
> URL: https://issues.apache.org/jira/browse/JCLOUDS-1426
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
>Affects Versions: 2.0.3
> Environment: AWS EC2
>Reporter: Dushyant Gupta
>Assignee: Andrea Turli
>Priority: Major
>
> I have made use of apache jclouds library to fetch ec2 instance details. I
> have attached 2 network interfaces on a single ec2 instance to provide it 2
> IPs.
> [!https://i.stack.imgur.com/xSHU3.png!|https://i.stack.imgur.com/xSHU3.png]
> But from the following code of jclouds, I see only one IP (of primary
> interface [eth0]) getting retrieved.
> {{ ComputeService cs = computeContext.getComputeService(); }}
> {{ for (ComputeMetadata cm : cs.listNodes()){ }}
> {{ NodeMetadata nm = (NodeMetadata) cm; }}
> {{ System.out.println(nm); }}
> {{ }}}
>
> In the output I can see only one IP address:
> {quote}privateAddresses=[172.26.119.234]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
