Currently, jclouds assumes that the <ID> must occur before the
<DisplayName> tag. If the XML body does not adhere to this order, the
parser throws a NullPointerException.
Scaleway is a cloud provider that does not adhere to this order and
returns the <DisplayName> tag before the <ID> tag. The patch changes the
parser to not depend on the order of the tags.
See commit 04feb8f848 for a similar fix
Previously s3 always used v2 and aws-s3 always used v4. Now s3
defaults to v2 and can override to v4. Note that this does not change
BlobRequestSigner.
Currently, jclouds assumes that the ListBuckets response follows a
specific order: the <Owner> tag, followed by the <Buckets> tag. Within
the <Owner> tag, jclouds further assumes that the <ID> must occur before
the <DisplayName> tag. If the XML body does not adhere to this order,
the parser throws a NullPointerException.
DigitalOcean spaces does not adhere to this order and returns the
<DisplayName> tag before the <ID> tag. The patch changes the parser to
not depend on the order of the tags.
XMLBuilder is a very nice fluent API for building XML documents.
However, it is only used by a tiny portion of jclouds: the s3 api. The
use of the XMLBuilder class requires a dependency to
com.jamesmurty.utils:java-xmlbuilder jar and a transitive
dependency to the net.iharder:base64 jar (superseded by
java.util.Base64 in java 8). They are 18kb each approximately and they
not OSGi compatible. They are not huge, but they represent more API
surface and more things to change when trying to use jclouds in an OSGi
context (they need to be replaced by OSGi compatible bundles like
org.apache.servicemix.bundles.java-xmlbuilder).
This commit replaces the use of XMLBuilder by a direct use of the
javax.xml and org.w3c.dom APIs.
I hope retesting will be minimal, and most of this code is covered by
unit tests.
* animal sniffer should be on java18, just like `<jdk.version>`
* Only use XMLBuilder's elem() and text() methods to have similar looking code
* Remove unnecessary call to XMLBuilder's up() because the returned value is never used
* Simplify code
* Deduplicate code
* Make the code more explicit by returning the rootBuilder
The x-amz-copy-source header on S3 CopyObject should be URL encoded (as
a path). This is not universally true of all headers though (for example
the = in x-amz-copy-source-range) therefore introducing a new parameter
on @Headers to indicate whether URL encoding should take place.
- move Neutron FloatingIP API from extension to feature
- introduce FloatingIpForServer as abstract domain object to represents Nova and Neutron objects
- manage floating ip cache and its invalidation
Mickael LANOE
Andrew Gaul
ramahin
didixith
Timur Alperovich
Jean-Noël Rouvignac
korlov42
gurkerl83
Sam Ottenhoff
Ignasi Barrera
David Currie
Jesse Glick
andreaturli
Chaithanya Ganta
Stephen Tomkinson