Had a look through this, looks good. The securityToken field in HttpRequest seems to be dead code. We should probably remove that field from either the HttpRequest class or the signing fetcher classes, having it in both is confusing.
Having the gadgetUrl available in the HttpRequest is a bit risky, that value can't be trusted unless it is pulled out of the security token. I have a slight preference for grouping parameters together into smaller classes, the umpteen fields in HttpRequest are a bit confusing. For example, signOwner and signViewer could be combined into SigningParams, etc... On Tue, Aug 19, 2008 at 6:14 PM, <[EMAIL PROTECTED]> wrote: > Author: etnu > Date: Tue Aug 19 18:14:33 2008 > New Revision: 687214 > > URL: http://svn.apache.org/viewvc?rev=687214&view=rev > Log: > Refactored HttpRequest into a more useful construct in order to facilitate > ongoing work for SHINDIG-523 and SHINDIG-517. > > This isn't really much of a change, it just touches a lot of files since it > replaces most usage of java.net.URI. > > Some interfaces at the edge of this code may need to be modified slightly, > especially if they looked at HttpRequest.getUri directly. We're now using > org.apache.shindig.common.uri.Uri instead of java.net.URI. If existing code > still wants a java.net.URI, some new utility methods have been added to Uri > to facilitate converstion. > > Much more work remains to be done in the rendering and network request > pipeline. The next step will be updating HttpResponse objects along the same > lines as HttpRequest (with some notable significant differences, since > responses must be immutable). Additional cleanup to remove remaining use of > java.net.URI would also be good, though not critical.
