Only JSR-286 (Portlet 2.0) portlets can be made remotable as the mechanism to expose a portlet to WSRP relies on the JSR-286-only functionality.
GateIn does
         not expose local portlets for consumption
         by remote WSRP consumers by default. 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.
      
In the following example, the "BasicPortlet" portlet is specified as being remotable.
<?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 the container-runtime-option at the portlet-app element level. 
		 Individual portlets can override that value to not be remotely exposed. Look at the below example:
      
<?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, the
         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.
         The 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.
      
	
		See also