For those who do not use Dagger, or do not wish to, this provides an alternate method of defining dependencies.
This includes logging config, decoders, etc. It still uses Dagger under the scenes, but doesn't require the user
to deal with the module system.
Decoder.Default's decoding to Response didn't actually work; the reader would always
be closed when used from Feign, as it depended on the url connection, which would
have been closed by the time the Response object was returned to the client.
This wasn't noticed because the default decoder tests don't use the mock web server.
There will be test coverage added for this shortly as part of the enhancements to
support a Builder.
This is intended as a step towards simplifying Feign.
This changeset removes the generics from both interfaces, and changes their
Dagger bindings from SET to UNIQUE.
Additionally, in changing the signatures for Encoder/Decoder, it focuses on use
of the RequestTemplate and Response objects, allowing us to extend them
in the future to support binary data without needing to change the
Encoder/Decoder signatures again.
They look something like this:
java.lang.NullPointerException
at feign.ReflectiveFeign$FeignInvocationHandler.invoke(ReflectiveFeign.java:88)
at feign.$Proxy16.equals(Unknown Source)
In my particular instance, I had a proxy created by Feign registered in a Spring application context,
and it resulted in a NullPointerException on application shutdown.
Enhances the default client to GZIP-encode request bodies when the appropriate
content-encoding header is set in the interface's method definition.
https://github.com/Netflix/feign/issues/52
Sometimes, it's useful to override the hostname verifier for SSL connections.
One example, would be when you're developing against a test server managed by
another company that's using a self-signed certificate with a mis-matched
hostname. This patch enables that usage by overriding the default
HostnameVerifier in a Dagger module.
Adding test coverage required switching the TrustingSSLSocketFactory from
using an anonymous cipher suite to one that authenticates. A test keystore is
used for this purpose. It contains two self-signed certificates, one
each with alias (and CN) "localhost" and "bad.example.com". The
TrustingSSLSocketFactory is no longer a singleton; it now
optionally takes a key alias as an argument.
adriancole
David M. Carr