Making a portlet remotable

GateIn does NOT, by default, expose local portlets for consumption by remote WSRP consumers. In order to make a portlet remotely available, it must be made "remotable" by marking it as such in the associated portlet.xml. This is accomplished by using a specific org.gatein.pc.remotable container-runtime-option. Setting its value to true makes the portlet available for the remote consumption, while setting its value to false will not publish it remotely. As specifying the remotable status for a portlet is optional, you do not need to do anything if you do not need your portlet to be available remotely.

<?xml version="1.0" standalone="yes"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
             version="2.0">
<portlet-app>
   <portlet>
      <portlet-name>BasicPortlet</portlet-name>

      ...

      <container-runtime-option>
         <name>org.gatein.pc.remotable</name>
         <value>true</value>
      </container-runtime-option>
   </portlet>
</portlet-app>

It is also possible to specify that all the portlets declared within a given portlet application to be remotable by default. This is done by specifying container-runtime-option at the portlet-app element level. Individual portlets can override that value to not be remotely exposed.

<?xml version="1.0" standalone="yes"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
             version="2.0">
<portlet-app>

   <portlet>
      <portlet-name>RemotelyExposedPortlet</portlet-name>
      ...
   </portlet>
   <portlet>
      <portlet-name>NotRemotelyExposedPortlet</portlet-name>
      ...
      <container-runtime-option>
         <name>org.gatein.pc.remotable</name>
         <value>false</value>
      </container-runtime-option>
   </portlet>

   <container-runtime-option>
      <name>org.gatein.pc.remotable</name>
      <value>true</value>
   </container-runtime-option>
</portlet-app>

In the example above, two portlets are defined. The org.gatein.pc.remotable container-runtime-option is set to true at the portlet-app level, meaning that all portlets defined in this particular portlet application are exposed remotely by GateIn's WSRP producer. Note, however, that it is possible to override the default behavior: specifying a value for the org.gatein.pc.remotable container-runtime-option at the portlet level will take precedence over the default. In the example above, RemotelyExposedPortlet inherits the remotable status defined at the portlet-app level since it does not specify a value for the org.gatein.pc.remotable container-runtime-option. NotRemotelyExposedPortlet, however, overrides the default behavior and is not remotely exposed. Note that in the absence of a top-level org.gatein.pc.remotable container-runtime-option value set to true, portlets are NOT remotely exposed.

Make portlets aware of WSRP requests

WSRP sets the org.gatein.invocation.fromWSRP (defined by the org.gatein.wsrp.WSRPConstants.FROM_WSRP_ATTRIBUTE_NAME constant) request attribute to Boolean.TRUE when the request initiated from WSRP. A portlet can therefore check whether a request is coming from WSRP and react specifically if so required, as follows:

if (!Boolean.TRUE.equals(request.getAttribute(WSRPConstants.FROM_WSRP_ATTRIBUTE_NAME)))
{
  // do something
}