For anything executing as a JSR-168 portlet there is no valid request.getServerPort() call. While technically you can access a HttpServletRequest object when rendering in a JSP that object should never be used, the portlet's request/response objects must be used instead. The main question is how are URLs generated, as Chris pointed out portlets must generate URLs through an API that takes care of the entire URL string. My guess is there is something else going on with URL generation for the portlet (string concatenation or some such) and the format just happens to be close enough to what uPortal expects to work.
-Eric Jason Shao wrote: > On Oct 2, 2007, at 5:54 PM, Anastasia Cheetham wrote: > >> Hi, everyone, >> >> We're observing a strange bug in a tool that we're deploying as a >> portlet in uPortal. I'm hoping that someone might be able to shed >> some light on it. >> >> The tool converts relative URLs to absolute URLs, but it's inserting >> a wrong port number. Our uPortal instance is running on port 8090, >> but the port number that turns up is 80. When the URLs are tested >> with the right port number substituted, they work. >> >> In case it matters: The tool is actually a Sakai tool that is wrapped >> as a portlet. When it runs within Sakai (which is running on port >> 8080) all is fine. No port number is included in the absolute URL, >> and in the Sakai context, this works. > > 1. "wrapped as a portlet?" are you using some kind of bridge servlet > (like the Struts-Bridge?) > > 2. What do the connectors in your server.xml look like? > > 3. (probably only applies if you're using a bridge servlet) If you > call request.getServerPort() what do you get? > > Jason > > -- > > Jason Shao > Application Developer > Rutgers University, Office of Instructional & Research Technology > v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | > http://jay.shao.org > > >
smime.p7s
Description: S/MIME Cryptographic Signature
