Hi Stanton, Sounds like we could use a little improvement to the logic. It does work for us, and has for some time, but for better robustness it couldn't hurt to make some edits.
Re: blank schema, that's for schema-relative URLs. Widely used in the code, largely b/c we don't have a convenient way to inject the current protocol being used. -j On Thu, Mar 31, 2011 at 7:09 PM, Stanton Sievers <[email protected]>wrote: > I don't think the gadget url is null, rather, this test is overriding the > LockedDomainPrefixGenerator to always produce "LOCKED". > > I find it interesting to see that these tests assert that the scheme is > "". Why is that? Shouldn't the renderingUri returned by makeRenderingUri > have a scheme, as it does in the non-locked domain case. > > These tests would also hit the exception if the locked domain suffix were > set to have a port number. A simple way to reproduce the issue I'm seeing > is set LD_SUFFIX in DefaultIframeUriManagerTest to be > ".lockeddomain.com:8080". > > Best regards, > -Stanton > > > > From: Ryan J Baxter/Westford/IBM@Lotus > To: [email protected], > Cc: Ziv Horesh <[email protected]> > Date: 03/31/2011 21:48 > Subject: Re: DefaultIframeUriManager for locked domains > > > > So I just ran the unit tests in DefaultIframeUriManagerTest,java and this > code does get hit. ldAddedForcedAlways seems to touch that code. This > test produces LOCKED.lockeddomain.com as a domain and Uri.parse does not > blow up on that. However I did notice that the gadget url in the test is > null, so I am not sure if this test is valid since you can't create a hash > > of that. Stanton, we probably want to take a deeper look at this test. > > -Ryan > > Email: [email protected] > Phone: 978-899-3041 > developerWorks Profile > > > > From: John Hjelmstad <[email protected]> > To: [email protected], > Cc: Ziv Horesh <[email protected]> > Date: 03/31/2011 09:06 PM > Subject: Re: DefaultIframeUriManager for locked domains > > > > Not when we run tests in Shindig... unless somehow that code path is never > hit. > > On Thu, Mar 31, 2011 at 5:42 PM, Ziv Horesh <[email protected]> wrote: > > > On Thu, Mar 31, 2011 at 4:18 PM, John Hjelmstad <[email protected]> > wrote: > > > > > Hi Stanton, > > > > > > Odd, this has worked for us for quite some time. Uri.parse(...) just > > > doesn't > > > throw a UriException. Are you overriding UriParser? > > > > > But we are overriding the parser... > > > > > > > > > > On Thu, Mar 31, 2011 at 2:57 PM, Stanton Sievers <[email protected] > > > >wrote: > > > > > > > Hi, > > > > > > > > Has anyone been able to use the DefaultIframeUriManager when locked > > > > domains are configured? I've configured > > > > gadgets.uri.iframe.lockedDomainSuffix in my container.js and have > set > > > > shindig.locked-domain.enabled=true in shindig.properties. I seem to > > be > > > > hitting the correct code paths, but I think the logic in > > > > DefaultIframeUriManager.makeRenderingUri() is incorrect. > > > > > > > > In the case where locked domains are enabled we do a string > > concatenation > > > > of the generated locked domain prefix and the configured > > > > gadgets.uri.iframe.lockedDomainSuffix in order to build the host > name. > > > The > > > > problem is that immediately after that we try to do Uri.parse() on > the > > > > host name which is throwing a UriException because we don't have a > > > > protocol/schema for the url, i.e., the url is just <gadget url > > > > hash>.mydomain.com instead of http://<gadget url hash>.mydomain.com. > > > > > > > > Does this just not work for the DefaultIframeUriManager and those > who > > > want > > > > locked domains need to bind to their own UriModule? > > > > > > > > Thanks, > > > > -Stanton > > > > > > > > > > > > > > > > > > > >
