I will spare you my rants about Java Server Faces h:commandLink for now. Suffice it to say that I can't believe that it is the simplest thing that could work. The fact that JSF doesn't allow for GET requests just seems bizzare in the extreme. I understand that some servers will choke on long get requests but please let the developers decide what to use.

There are two easy mistakes to make when using h:commandLink. The first is so simple as to almost not be worth mentioning but here goes anyway. You have to include the h:commandLink inside a h:form thus:

<h:form>
	<h:commandLink action="some_action">
		<h:outputText value="#{text.some_text}"/>
	</h:commandLink>
</h:form>

or you get and error message along these lines (note this is the root cause you may see other errors above this one)

The second mistake with h:commandLink is one that if it catches you out will confuse you for hours before you figure out what is going on. You will fall foul of this feature if you use a a combination of Tomcat, XML JSP files (.jspx) and Firefox. Tomcat will set the content type of the page to text/xml if you are using XML JSP pages which Firefox renders fine as HTML (IE just displays the XML). The commandLink creates anchors with this format <a href="#" onclick="...">foo</a> which, when the content type is text/xml, don't cause the page to be refreshed hence your commandLink doesn't seem to work. The solution is to set a jsp directive such as:

<jsp:directive.page contentType="application/xhtml+xml"/>
<jsp:directive.page contentType="text/html"/>

or better than that configure tomcat to send one of those headers automagically. Beware the pile of proverbial that is IE though when sending the content type application/xhtml+xml because it won't work (http://www.w3.org/MarkUp/2004/xhtml-faq#texthtml)