On the surface it appears to be broken primarily because the "fetch" method, when determining that a call to the request_token URL is required (i.e. "needApproval()" is true), that the RemoteContent object returned is explicitly null.
The new ProxyHandler code cannot deal with a null response object (specifically because it begins to loop through the response metadata content, and, well, it's null = NullPointerException swallowed neatly up by the container and shunted off to the great bitbucket in the sky). Then, to compound the issue, the approval URL info returned from the OAuthFetcher is expected to reside in the cnotent metadata. Again, if explicitly returning a null content object, that's pretty tricky to load up with metadata. Perhaps it should be returning an Unauthorized object with metadata (i.e. header) content, that actually *tells* the calling client code that you're not yet authorized, and so trigger the need to look further for approval URL and state token content. However - I don't feel confident enough of my appraisal to offer actual code, for fear I'll completely miss that ol' moving target. ...On that topic, I've got another problem related to this, when the Oauth provider expires it's issued tokens, and the current Shindig Oauth implementation never allows that information to propogate anywhere, leaving a poison token cache in place to stop all subsequent requests from the issuing gadget from ever being succesfully authenticated ever again, but for the moment, that's a completely different problem (which I'll be happy to explore further when the basic functionality is back in action). For the first time, -Shaun -----Original Message----- From: Kevin Brown [mailto:[EMAIL PROTECTED] Sent: Monday, April 28, 2008 1:32 PM To: [email protected] Subject: Re: [Java] ContentFetchers are a mess. On Mon, Apr 28, 2008 at 10:53 AM, Brian Eaton <[EMAIL PROTECTED]> wrote: > On Mon, Apr 28, 2008 at 12:11 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > Between code migration, patches, cross talk, misinformation, and > > mass confusion, we seem to have gotten into a state of complete > > dysfunction > when > > it comes to our http retrieval facilities. Is anyone else actively > working > > on cleaning this stuff up right now, or should I go ahead and clean > this up > > myself? > > The OAuthFetcher is flat out broken since the caching change. It'd be > good to get it fixed before refactoring. > > What are your goals for this round of refactoring? Performance? > Readability? Ease of adding some particular new feature Primarily readability, maintainability (hahahah...), and ease of extending / modifying. I've been able to force it to working for the google implementation, but it's ugly as sin and relies on several unnecessary workarounds. I didn't realize that OAuthFetcher was completely broken. I thought it was just "mostly broken" :).
