OSGi bundle for jclouds-okhttp should import okio package with correct
version range.
Currently, there is no version range specified, causing it to be wired
to a higher version than intended in complex environments that have more
than one bundle for okio installed.
Switched from Properties to HashMap to fix compilation issues. Where
Properties is not of type Dictionary<String, ?>. This passes the right
type to bundleContext.registerService. Also corrects the first argument,
String -> String[], same issue wrong type passed.
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
This method has incorrect results when run on Windows. It is expected to
generate folder names compatible with Unix-like target machines, but by
using File.getParent it will actually be influenced by the host machine
OS type. This results in baseDir being set to a style that will not work
on Unix-like targets.
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'
The default network of recently created projects have a null value for rangeIPv4
And all regions as subnets, which do have values for the rangeIPv4.
Fixes JCLOUDS-1158
* 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
When Class.forName is called for a class in a different bundle it will
fail as the default karaf class loader won't load classes from other
bundles.
I have fixed this by using the classloader of the original
(non-autovalue) type and assuming it will be in the same bundle as the
autovalue type (I think this is a reasonable assumtion).
So far the only place where I've actually seen this being an issue is
when using the jclouds-labs-google provider within karaf. It fails
when serialising the Firewall.Rule class within a FirewallOptions
object.