I'd like to see the .java code in question. In general Portlets should
not know things like hostname/port number of urls, they should be using
the PortletContainer to get/create/generate the URLs. The
PortletContainer then has the opportunity to provide a tokenized URL
that it then "fills" in later AFTER the portlet is done running.
---- Cris J H
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.
--
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
