The PortletResponse.encodeUrl() in WSRP portlet

In the How the PortletResponse.encodeUrl() method works method i mentioned that the PortletResponse.encodeUrl() method does not have any effect on the URL generated.But you must use it if you want your static resource serving to work in the WSRP Portlet.

I do have this sample ResourceServing.war portlet, which is very simple only thing that the Portlet does is forward control to the resource.jsp. And the resource.jsp includes a sampleimg.gif file in the markup like this


<%@page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1" session="false"%>
<%@taglib uri="http://java.sun.com/portlet" prefix="portlet"%>
<%@taglib uri="http://www.ibm.com/xmlns/prod/websphere/portal/v6.1/portlet-client-model" prefix="portlet-client-model"%>
<%@taglib uri="http://java.sun.com/portlet" prefix="portletx"%>

<portlet:defineObjects />
<b><img src='<%= renderResponse.encodeURL("renderRequest.getContextPath() + "/sampleimg.gif") %>' /></b>


As i mentioned in the previous post the renderRequest.getContextPath() returns the context root where your portlet application is installed. Which is sufficient to get URL to resource. But in case of WSRP that is not sufficient. In case of WSRP the request for /sampleimg.gif should first go to the consumer portal which will do the tunneling to get the request from the producer portal (If your producer portal is directly available to the user then you can also create hard-coded URL pointing to the producer portlet in the markup but its not recommended practice)

In case when the ResourceServing portlet is served through WSRP the above JSP will generate this HTML Markup

<img src="/wps/WsrpProxyPortlet/ResourceProxy/PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48dT48Yj5odHRwOi8vbG9jYWxob3N0OjEwMDQwPC9iPjxwPjxuPndzcnAtc2VjdXJlVVJMPC9uPjx2PmZhbHNlPC92PjwvcD48cD48bj53c3JwLXVybFR5cGU8L24-PHY-cmVzb3VyY2U8L3Y-PC9wPjxwPjxuPnA8L24-PHY-MTJfVlZJTE1LRzEwODVGOTBJUzQ0SlJRNTMwMDc8L3Y-PC9wPjxwPjxuPmc8L24-PHY-MV9WVklMTUtHMTA4NUY5MElTNDRKUlE1MzAwMDwvdj48L3A-PC91Pg!!/SjPAEvQqcAICDYyb-sViNKWZad0!/wps/PA_ResourceServing/sampleimg.gif">


As you can see the image URL is pointing to the consumer portal server at /wps/WsrpProxyPortlet/ResourceProxy then there is a big token with session information,.. And at the end of the URL is the actual URL of the sampleimg.gif on the producer portlet.

I thought i should take a closer look at /wps/WsrpProxyPortlet/ResourceProxy URL. THe /wps/WsrpProxyPortlet points to the PA_PortalWSRPProxy.ear file. The application.xml for that file is like this

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application id="Application_ID">
<display-name>wsrpproxy_war</display-name>
<module>
<web>
<web-uri>wsrpproxy.war</web-uri>
<context-root>/wps/WsrpProxyPortlet</context-root>
</web>
</module>
</application>


The PA_PortalWSRPProxy.ear has wsrpproxy.war file which includes the com.ibm.wps.wsrp.consumer.std.impl.ProxyPortlet portlet, which is proxy portlet for consuming WSRP portlet. WHen i looked at the web.xml for that portlet it has a com.ibm.wps.wsrp.consumer.std.impl.ResourceProxy Servlet which is supposed to handle the /ResourceProxy URL.


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app id="com.ibm.wps.wsrp.proxyportletapp">
<display-name>PortalWSRPProxyPortlet</display-name>
<servlet>
<servlet-name>resourceproxy</servlet-name>
<servlet-class>com.ibm.wps.wsrp.consumer.std.impl.ResourceProxy</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>resourceproxy</servlet-name>
<url-pattern>/ResourceProxy/*</url-pattern>
</servlet-mapping>
</web-app>



In case of WSRP portlet, when it comes to serving a static request, it will first go to the the ResourceProxy servlet on the consumer portal and then ResourceProxy servlet will forward it to the producer portal for getting response and then return that response to the browser

No comments: