Bug 981746

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 ? "&amp;" : "&";

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/>