The ContainerApiLiveTest class has tests that mostly assume that a
single test container always exists. They collide on changes to the
state of the container. Some of the tests, though, assume the
container does _not_ exist and attempt to create it and subsequently
delete it. The change in this patch makes their behavior uniform with
respect to that test container: assume it exists and if the test tries
to delete it or mutate it, delete the container and create it at the
end of the test.
The fix in ObjectApi is for the Object GET requests. Currently,
jclouds passes "format=json", which is not a supported query parameter
for object GET.
Lastly, ObjectApiLiveTest that test server-side copy should ignore the
X-Openstack-Request-ID header, as its value will change between the
two requests.
Newer JDK have a different resolution process, likely due to enhanced
target type inference. Found via:
mvn test -Dmaven.compile.source=1.8 -Dmaven.compile.target=1.8
This makes dependencies consistent and eliminates warnings of the
form:
$M2_HOME/repository/org/apache/jclouds/driver/jclouds-slf4j/2.1.0-SNAPSHOT/jclouds-slf4j-2.1.0-SNAPSHOT.jar(org/jclouds/logging/slf4j/config/SLF4JLoggingModule.class): warning: Cannot find annotation method 'value()' in type 'AutoService': class file for com.google.auto.service.AutoService not found
Reference:
https://github.com/google/auto/tree/master/service#download
This makes dependencies consistent and eliminates warnings of the
form:
$M2_HOME/repository/org/apache/jclouds/driver/jclouds-slf4j/2.1.0-SNAPSHOT/jclouds-slf4j-2.1.0-SNAPSHOT.jar(org/jclouds/logging/slf4j/config/SLF4JLoggingModule.class): warning: Cannot find annotation method 'value()' in type 'AutoService': class file for com.google.auto.service.AutoService not found
Reference:
https://github.com/google/auto/tree/master/service#download
- wait for serer deletion, before deleting the security group
- rename cleanupServer to cleanupResources
- remove keyPairCache
- better usage of tags to remove securityGroups created by jclouds
- remove keyPair after the creation of a group
- remove test for create unique keypair
- openstack nova re-adding support for existing keypair
- fix securityGroupApi check
- fix other unit tests
- remove ServerPredicates as it is now duplicated
- remove TemplateOptions.securityGroupNames as deprecated
- address commits for ApplyNovaTemplateOptionsCreatesNodesWithGroupEncodedIntoNameAndAddToSet
- fix testCreateNodeWhileUserSpecifiesKeyPairAndUserSpecifiedGroups
The intention is to use @SinceApiVersion for this purpose, but that
would affect a number of APIs, and we would want to have good test
coverage before merging that change (in
FormSignerUtils#getAnnotatedApiVersion). However, there is some issue
wth certain tests at resent that means we cannot successfully test
all APIs that make use of @SinceApiVersion in order to assure
ourselves that FormSignerUtils will not introduce some problem.
See https://github.com/jclouds/jclouds/pull/1102#issuecomment-302682049
for details.
This annotation is introduced as a temporary measure in order to
decouple the functionality of FormSignerUtils#getAnnotatedApiVersion
from @SinceApiVersion and the tests in question. It can be removed and
replaced by @SinceApiVersion when those tests are fixed.
Designates that a method overrides the {@link ApiVersion} on the class
with a specific value.
This fixes a bug where previously BindManifestToJsonPayload used the
character length as the ContentLength, instead of the byte length,
which caused issues if the JSON contained multi-byte Unicode
characters.
For https://issues.apache.org/jira/browse/JCLOUDS-1235.
This change takes the approach of storing the information about the
overall list of groups within the `SecurityGroupInRegion` when it is
created, so that any subsequent conversion operation has access to all
the groups in the same region as the one to be converted.
It also collapses the functionality of `NovaSecurityGroupToSecurityGroup`,
`SecurityGroupRuleToIpPermission` and `FindSecurityGroupWithNameAndReturnTrue`
all into `NovaSecurityGroupInRegionToSecurityGroup`, and deletes the
now unused-classes SecurityGroupRuleToIpPermission,
NovaSecurityGroupToSecurityGroup and associated tests.
When making a GetBucketLocation request, Amazon may route the request
to the bucket region. When making it with v4 signer, the request may
fail because of the region mismatch. Concretely, a request to
test.s3.amazonaws.com may resolve to s3-us-west-2-w.amazonaws.com. The
request itself is prepared for the us-east-1 region (s3.amazonaws.com
endpoint), but then fails when the DNS resolution points to a
us-west-2 endpoint.
Bucket-in-path works around this for the GetBucketLocation requests.
That means that every GetBucketLocation request will be of the form:
https://s3.amazonaws.com/{bucket}?location. This ensures that jclouds
requests will not be subjected to Amazon's routing/DNS pointers.
Fixes: JCLOUDS-1213
"Everyone" in a french Windows is "Tout le monde".
Thus, the line.split(" ") returns only "Tout" and putBlob() throws an exception.
The modified regex search for the first two consecutive white char to return the name.
Windows's whoami returns a bunch of 0x20 between the name and the type.
These classes should not close the release the payload as they are not
reading it.
- fix swift
- fix openstack-swift v1 and v2
- fix RetryOnRenewTest for v1 and v2
Readers can confuse this with 1. Found via error-prone. Fixed via:
find -name \*.java | xargs sed -i 's/\( [0-9][0-9]*\)l/\1L/g'
find -name \*.java | xargs sed -i 's/\(([0-9][0-9]*\)l/\1L/g'
* dynamically call TypeToken.isSupertypeOf with Guava 19 and later and
TypeToken.isAssignableFrom with Guava 18 and earlier
* consume or ignore values from methods with CheckReturnValue
* replace usage of removed Iterators.emptyIterator
Today the filesystem blobstore provider use the extended attributes of the
filesystem to store metadata. This is not always desirable as some filesystems
(such as NFSv3) do not support extended metadata. The current source code does
not allow to change this easily. getUserDefinedFileAttributeView could easily
be overriden for this purpose and allow extensions that customize where the
metadata should be stored.
See also JCLOUDS-658