Looks like we are out of luck. According to the spec, section 11.1.4:

Depending on the underlying web-server/servlet-container and the portal/portletcontainer
implementation, client request HTTP headers may not be always available.
Portlets should not rely on the presence of headers to function properly.

Not being one to give up easily, I came up with a workaround patch to the portal. Edit the file .\portlet\src\main\org\jboss\portal\portlet\impl\jsr168\PortletRequestDispatcherImpl.java adding the import:

import java.util.Enumeration;

HttpServletRequest wrappedReq = new HttpServletRequestWrapper(req)
{
 /**
 * Override the behavior from tomcat, see above.
 *
 * @return the null value per the spec
 */
 public StringBuffer getRequestURL()
 {
 // Per the spec
 Exception e = new Exception("called getRequestURL");
 e.printStackTrace();
 return null;
 }

 public Enumeration getHeaders(String hdr) {
 Enumeration result = null;
 if ("accept-language".equals(hdr)) {
 result = new Enumeration() {
 int i = 0;
 public boolean hasMoreElements() {return i == 0;}
 public Object nextElement() {i++; return "";}
 };
 }
 return result;
 }

};

Apparently no-one in the portal team is interested in getting the JSTL to work with the portal.* But for those poor souls who are still wrestling with this and don't want to make my suggested patch, I just came across a hidden, top secret tag** supplied by the JBoss portal: i18n. This tag provides similar functionality as the standard fmt:message tag. To see its usage, look at the file jboss-portal.sar/portal-core.war/WEB-INF/jsp/user/register.jsp. That's all for now, I'm off to convert my JSPs to use the i18n tag.

* Actually, I understand this sentiment. Sometimes what appears to be a small, innocuous change can really cause havoc or other forms of untold misery. So I understand why the portal team would be hesitant to adopt the patch. Perhaps I should have placed a smiley face next to my comment; the comment is a jest, not a complaint.

**I grepped for 'i18n' in the portal docs directory and did not get any hits, therefore it must be top secret.

Thanks Roy: JBPORTAL-984.

To everyone else following this saga, looks like the i18n tag isn't a good alternative. Apparently the class that implements it expects an HttpRequest object to be in thread local storage, but when called from my portlet code, there is no HttpRequest object so I get an NPE:

2006-08-17 14:48:12,851 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/image].[jsp]] Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
 at org.jboss.portal.core.servlet.jsp.taglib.PortalLib.getMessage(PortalLib.java:53)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.apache.commons.el.FunctionInvocation.evaluate(FunctionInvocation.java:172)
 at org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:263)
 at org.apache.commons.el.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:190)
 at org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate(PageContextImpl.java:932)
 at org.apache.jsp.WEB_002dINF.jsp.edit_jsp._jspService(edit_jsp.java:98)
 at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
etc.

Julien,

Actually, the JSTL code calls getHeaders, not get Header. Not sure why, especially since it never looks at the results, except to see if the returned Enumeration has at least one entry. So the proper patch for fmt:message is:

public Enumeration getHeaders(String s)
 {
 return rreq.getProperties(s);
 }

Sounds fine by me.

Thanks, Julien.