Test-Scenario via WSRP: Step 1: We have a remote portlet with a resource link and the attribute “escapeXML=”true” <a href="<portlet:resourceURL id="pdfResourceURL" escapeXml="true" />">escaped resource link</a><br/> Step 2: If we are calling the remote portlet, the generated url is not encoded and looks like: …&windowid=32ca0b9a-9b72-43cc-b84d-d18c2dfecf8e-&mode=view">escaped resource link</a><br/> Step 3: If we are calling the portlet on a local jboss, the url is encoded. Pre-analysis 1) Local-Portlets: If the portlet is called on a local jboss the class "org.gatein.pc.controller.impl.PortletURLRenderer" is used, which takes care about the encoding issues: format.getWantEscapeXML() == Boolean.TRUE ? "&" : "&"; 2) Remote-Portlets: If the portlet is called on a remote jboss the class "org.gatein.wsrp.producer.handlers.processors.WSRPPortletInvocationContext" (method: renderURL) is called which ignores the the "wantEscapeXML" flag of the URLFormat and does not encode the url. Workaround We also found a workaround for remote portlets with the help of the c:out tag. So we are saving the URL in a variable and using the escape functionality of the c:out tag. <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <portlet:resourceURL var="pdfResourceVar" id="pdfResourceURL" escapeXml="false" /> <a href='<c:out value="${pdfResourceVar}" escapeXml="true"/> '>ESCAPED true</a><br/>