What is Aggregation?

The portal provides a consolidated view of multiple content sources, or portlets, in a single browser display. The process of consolidating and rendering this content together is known as aggregation. In Jetspeed, the aggregator is made up of several pluggable Spring components that plug into the Jetspeed engine.

Supported Aggregators

List of Aggregators:

Component Name Description Multithreaded? JSR-168 Caching?
PageAggregator Given a PSML page, aggregates the content of all portlets on that page. no yes
AsyncPageAggregator A multi-threaded, asynchronous PSML page aggregator. yes yes
PortletAggregator Renders the content of one single portlet. no* yes
AsyncPageAggregator + CommonJ A multi-threaded, asynchronous PSML page aggregator running CommonJ Work Monitor threads, tested only with IBM Websphere 6.1 only. yes yes
* multi-threading is accomplished with the Jetspeed Desktop combined with the PortletAggregator

Aggregator Spring Configuration

                
        <!-- Default portlet timeout in milliseconds:
        Zero means no portlet timeout option by default.
        -->
        <constructor-arg>
            <value>0</value>
        </constructor-arg>

Changing the Page Aggregator to Multithreaded

The default aggregator is single-threaded. To switch to multi-threaded, edit the pipelines.xml spring configuration file: 

                
<!-- Before -->
  <bean id="aggregatorValve"
        class="org.apache.jetspeed.aggregator.AggregatorValve"
        init-method="initialize"

   <constructor-arg>
       <ref bean="org.apache.jetspeed.aggregator.PageAggregator"/>
   </constructor-arg>
  </bean> 

  <!-- After -->
  <bean id="aggregatorValve"
        class="org.apache.jetspeed.aggregator.AggregatorValve"
        init-method="initialize"

   <constructor-arg>
       <ref bean="org.apache.jetspeed.aggregator.AsyncPageAggregator"/>
   </constructor-arg>
  </bean>

jetspeed-portlet.xml Parameters

For the multithreaded aggregator, you can override the default setting for rendering timeout for a specific portlet. This value is set in milliseconds and represents the timeout value that Jetspeed will give the portlet to complete rendering before it gives up.

IMPORTANT: This parameter serves two purposes: (1) the presence of it enables parallel rendering for a portlet, and (2) the value determines how long Jetspeed will give this portlet to complete rendering before it times out and abandons rendering the portlet. Future versions will relax the first requirement. Beware that even if parallel rendering is enabled, portlets will not be rendered outside the main thread group, i.e. in sequential, unless this timeout parameter exists in the jetspeed-portlet.xml. 

                
<portlet>
        <portlet-name>PickANumberPortlet</portlet-name>
        <js:metadata name="timeout">3000</js:metadata>
</portlet>

Multithreaded Aggregation with Websphere

Running mulithreaded aggregation with Jetspeed requires the following configuration steps. Note that steps 1 and 2 are required for all Websphere installations and are not specific to multithreaded aggregation.

1. Login Filter

Configure the WEB-INF/web.xml to use the PortalFilter for logging in by uncommented the PortalFilter and its mapping:

                
  <filter>
    <filter-name>PortalFilter</filter-name>
    <filter-class>org.apache.jetspeed.login.filter.PortalFilter</filter-class>   
  </filter>
...
  <filter-mapping>
    <filter-name>PortalFilter</filter-name>
    <url-pattern>/*</url-pattern>    
  </filter-mapping>

2.Portal Login Portlet

Edit the default-page.psml, changing the login portlet to the filter-based login portlet as shown below. Make sure to also change the fragment id. Change:

                
    <fragment id="dp-12" type="portlet" name="j2-admin::LoginPortlet">
    ...

to ..

                
    <fragment id="dp-12a" type="portlet" name="j2-admin::PortalLoginPortlet">
    ...

3. Use the Jetspeed Portal Request Factory

Some webcontainers like WebSphere 5.x derive critical information of the HttpServletRequest dynamically from the current application context. This means that in an invoked portlet application, the original Portal request, as stored in the RequestContext, for example doesn't returns the Portal contextPath, servletPath and HttpSession of the Portal application. You'll get the same object references as in the current application HttpServletRequest. Because of this, simple things as portal level login through a custom portlet isn't possible in these web containers.

To solve this, an additional PortalRequest wrapper will be used which registers the initial (portal) object references from a supplied request and always returns those, instead of delagating to the wrapped request. Which wrapper is used is handled by a new PortalRequestFactory which can be specified in the springframework configuration. For other web containers like Tomcat which doesn't have this "problem", nothing has to be specified (none is by default), in which case the request will be wrapped in an HttpServletRequestWrapper to maintain the same level of wrapping (needed for easy access to the original request in ServletPortletInvoker.

Edit WEB-INF/assembly/wps.xml, and uncomment the one bean found there

            
<beans>   
    <!-- required for websphere, uncomment if running under websphere
         see:  http://issues.apache.org/jira/browse/JS2-355 -->
    <bean id="org.apache.jetspeed.request.PortalRequestFactory" class="org.apache.jetspeed.request.PortalRequestFactoryImpl"/>   
</beans>

4. Turn on the Multithreaded Aggregation Engine

Swap out the (org.apache.jetspeed.aggregator.PageAggregator) with the multithreaded aggregation engine in WEB-INF/assembly/pipelines.xml: 

            
  <bean id="aggregatorValve"
        class="org.apache.jetspeed.aggregator.AggregatorValve"
        init-method="initialize"
  >
   <constructor-arg>
       <ref bean="org.apache.jetspeed.aggregator.AsyncPageAggregator"/>
   </constructor-arg>
  </bean>

Optional Replacement for Portlet Request/Response Unwrapper

You can replace the default portlet request/response unwrapper with a third-party module in WEB-INF/assembly/pluto-factories.xml.

Because the servlet request object of a servlet container could not be thread-safe under Jetspeed parallel rendering mode, the third-party unwrapper module can provide a thread-safe implementation by decorating the original request object.

Here's an example setting for third-party unwrapper module:

            	
  <!--  
  PortletRequestResponseUnwrapper finds servlet request or servlet response from portlet request or portlet response by unwrapping.
  Third-party module can provide an implementation to decorate the real request or response object of a servlet container.
  For example, the real request object of a servlet container can be decorated because it is not thread-safe under Jetspeed parallel rendering mode.
  -->
  <bean id="PortletRequestResponseUnwrapper"
        class="com.bluesunrise.jetspeed.container.invoker.WebspherePortletRequestResponseUnwrapper" />

Optional CommonJ Work Manager

If you want to use Commonj Work Manager provided by the container, uncomment the followings in WEB-INF/assembly/aggregation.xml:

            			
    <bean id="JetspeedWorkManager" class="org.springframework.jndi.JndiObjectFactoryBean">
        <property name="resourceRef"><value>false</value></property> 
        <property name="jndiName">
            <value>java:comp/env/wm/jetspeed</value>
        </property>
    </bean>
    <bean id="org.apache.jetspeed.aggregator.CommonjWorkerMonitor"
          class="org.apache.jetspeed.aggregator.impl.CommonjWorkerMonitorImpl"
          init-method="start"  destroy-method="stop" >
        <constructor-arg index="0">
            <ref bean="JetspeedWorkManager" />           
        </constructor-arg>
    </bean>

Also replace all references to org.apache.jetspeed.aggregator.WorkerMonitor with org.apache.jetspeed.aggregator.CommonjWorkerMonitor in WEB-INF/assembly/aggregation.xml.