Unlike last attempt this replaces Fog::Connection with
Fog::XML::Connection which should be directly compatible.
Fog::Connection is there for old PRs but should be removed real soon.
Providers using JSON should be able to replace "XML" with "Core" within
their code to cut down on the dependency.
If I get the time I may attempt to clean up some but testing with Mock
will mean that is mostly educated guesswork.
Fog::Connection mixed in XML parsing via the `parser` argument which
wasn't much use for the majority of APIs using JSON.
This adds the deprecation warning and attempts to update providers to
the correct version of Connection that they need.
Either the cleaner `Fog::Core::Connection` or if reliant on the XML
parsing still `Fog::XML::SAXParserConnection`
The SAX parser will be moving to `fog/xml` fairly soon.
Match against the error object in both the old (against error.message)
and the new (against error.response.body); return a hash from this
method.
In the rescue block, try hard to raise an exception that includes the
code and message extracted from the error.
Recent versions of excon have a middleware component,
Excon::Middleware::Expects and fog requests mostly record an expectation
of a 200 status code. Some calls to AWS return status other than 200 and
in some cases the error handling obscures the underlying error.
Current handling parsed error.message; this instance of error is
constructed by excon and includes the response as an attribute. The
message is always something like 'Expected(200) <=> Actual(404 Not Found)'
and so the parsing never succeeds.
Instead we now attempt to parse error.response.body which should allow
extraction of the underlying AWS Code value, which in turn will produce
an exception that points to the actual underlying cause.
Should facilitate the following:
require 'fog/aws'
require 'fog/compute'
require 'fog/aws/compute'
I think once you `require 'rubygems'` those should work.
further cleanup should reduce common requires (ie nokogiri)
