title: Liferay renderURL loads the same page
body: <p>I developed a portlet which gets called on condition via <code>&lt;liferay-portlet:runtime portletName="2903"&gt;&lt;/liferay-portlet:runtime&gt;</code> inside another portlets view.jsp</p>
  
  <p><strong>Explanation:</strong> PortletA::view.jsp does check which Theme is currently applied and then either loads PortletB or keeps processing its own code.</p>
  
  <p>It's a mobile version of the OOTB message boards portlet and it does work on Tomcat 7.0.27 which I use for development.</p>
  
  <p><strong>Problem:</strong> The live server is Websphere and after the deployment process all links that were created with renderURL taglib don't work, e.g. after a click the same page just gets reloaded and nothing happens. The tags look like this:</p>
  
  <pre><code>&lt;portlet:renderURL var="editURL"&gt;
          &lt;portlet:param name="struts_action" value="/mobile_message_boards/edit_message" /&gt;
          &lt;portlet:param name="redirect" value="&lt;%= currentURL %&gt;" /&gt;
          &lt;portlet:param name="messageId" value="&lt;%= String.valueOf(message.getMessageId()) %&gt;" /&gt;
      &lt;/portlet:renderURL&gt;
  </code></pre>
  
  <p><strong>Observed:</strong>
  The posted snippet does produce a working link on Tomcat but not on Websphere. When I use <code>&lt;portlet:actionURL&gt;</code> instead of <code>&lt;portlet:renderURL&gt;</code> it also works on Websphere, but is not a clean implementation.
  When I add the mobile version portlet individually/directly into a page the renderURL do work again as expected redirecting to appropriate pages, but then I lose my condition which determines which portlet should be loaded. I've added some tracing into the PortletAction that is behind the struts, but it is never called on Websphere, while on Tomcat the tracing appears in the Log output.</p>
  
  <p>I believe it has something to do with some config rights for creating/calling renderURL of portletB inside portletA on Websphere. I didn't find any viable solution for this issue.</p>
  
  <p>Does anyone know a solution or a workaround? </p>
  
  <p>Kind Regards,
  Denis Dik</p>