I've done some additional research and it looks like this issue is caused by our assumption that resource URLs should never have an associated window state. Since the window state isn't set, the URL generation code defaults to normal, and the UrlCanonicalizingFilter then issues a 302 redirect.
Is there a good way to include the window state in the URL without breaking the portal's logic? Right now we have a precondition in PortletUrlBuilder.getWindowState() that prevents resource URLs from having a window state, so it's not just a matter of adding the window state back into the URL, I don't think. - Jen On Sep 5, 2011, at 4:21 PM, Eric Dalquist wrote: > Looks like it is probably a problem in the UrlSyntaxProviderImpl I'm not > going to have a chance to take a look until after the 14th so if you're > interested the easiest way to figure out the problem is to add another unit > test to UrlSyntaxProviderImplTest (look at the diff against the previous > version for an example, I just added a new test right before the release) > then you can just work in the unit test to figure out why the parser isn't > happy with the detached UrlState for a resource UrlType. > > -Eric > > On 9/2/11 11:51 AM, Jen Bourey wrote: >> We've run across an issue in the uPortal 4 codebase that affects AJAX >> portlets in detached mode. Essentially it appears that resource URL calls >> against the detached URL are issued a 302 redirect to the normal URL, like >> so: >> >> http://localhost:8080/f/u12l1s5/p/news.u12l1n7/detached/resource.uP?pCc=cacheLevelPage >> -> >> http://localhost:8080/f/u12l1s5/p/news.u12l1n7/normal/resource.uP?pCc=cacheLevelPage. >> >> This redirect only seems to occur in detached mode (not maximized), and only >> on the desktop (not mobile) theme. I'm guessing that this might have to do >> with a difference in the syntax node helpers, but I've yet to find anything >> that looks to be causing it. >> >> While this shouldn't actually break functionality, there also seems to be >> some sort of other issue with the redirected URL that's breaking the >> content. I'll do further debugging, but I don't think we want to be using >> 302 redirects anyway since it will affect the browser-side performance of >> the page. >> >> - Jen >> >> > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
