dont conflict with twitter library

osbornebrook commented 10 years ago

Without this patch, if I have the twitter gem loaded in my app at the same time as this one, the LinkedIn faraday connection ends up with Twitter::REST::Response::RaiseError in its middleware chain rather than the Faraday::Response::RaiseError that it's expecting. The corresponding registration in the twitter gem is in the file lib/twitter/rest/response/raise_error.rb

I've looked inside faraday and it seems like these registrations should be scoped to the subclasses that each library makes for itself, but that's clearly not happening here. All in all the whole thing is ungodly complicated considering it just makes HTTP requests, there's a mutex controlling access to some kind of structure containing various constants that the library has modified, (I think) and basically I'm not interested in touching any of it with a ten foot pole. (I'm sure it's very heavy duty code and its like that for a good reason but I just don't have the time to wade into it.)

This patch doesn't break any tests so I'm leaving it here in case anyone has the same problem.

coveralls commented 10 years ago

Coverage remained the same when pulling 2b90fd4513f1bf5e9a521b3425a99fb6ca249cd8 on osbornebrook:master into 6b0e02452bbb0a07ef6eb1949bba2cc8668ba008 on emorikawa:master.

coveralls commented 10 years ago

Coverage remained the same when pulling 75a80c15cd4ca6af986c9ce08120a3280c1d252c on osbornebrook:master into 6b0e02452bbb0a07ef6eb1949bba2cc8668ba008 on emorikawa:master.

nlsrchtr commented 9 years ago

:+1:

emorikawa / linkedin-oauth2

dont conflict with twitter library #15