If other portlets, like the pluto testsuite that is included, are rendering correctly then my guess would be a problem in the URL generation of the portlet in question. Could you post an example of how one of the 'bad' URLs is generated in the code/jsp/etc?
-Eric 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. > > I've done a bit of searching, and I've seen references in the past to > bugs in some getServerPort() implementations, for example when using > the Axis tcpmon packaged as a plug-in for IntelliJ. I don't know if > something like this might be going on? > > It's also possible that there might be something set up wrong in our > Apache configuration, though we haven't seen any other problems. I am > looking into that possibility. > > > I'm sorry if my question is a big vague, but I'm really not sure what > the problem is. I do realize that this might not be a uPortal issue, > but I thought just in case this has been seen before, I'd ask. > > If anyone has any suggestions, I'd be very grateful. > > >
smime.p7s
Description: S/MIME Cryptographic Signature
