Chapter 11. Portal Life-cycle

11.1. Application Server Start and Stop

A portal instance is a set of web applications deployed as EAR and WAR archives. Portlets are also part of an enhanced WAR called a portlet application.
Red Hat JBoss Portal (JBoss Portal) does not require any particular setup for portlets in most common scenarios, and the web.xml file can remain without any JBoss Portal specific configuration.
During deployment, JBoss Portal will automatically inject a servlet into the portlet application to be able to interact with it. This feature is dependent on the underlying servlet container but will work out of the box on the proposed bundles.

11.1.1. Advanced WCI Registration

The portal integrates with the web container to perform tasks such as automatic detection and registration of web applications. This is used by the portal container to detect when portlets are deployed and is accomplished through the WCI (Web Container Integration) component.
Some applications, particularly Spring based portlets, may have requirements that specific servlets are started before any portlets are initialized. Although portlets and servlet initialization order are meant to be independent of each other, Red Hat JBoss Portal provides a method to circumvent limitations imposed by these specific third-party applications.
As a workaround to this issue, the following advanced features have been integrated into the WCI component;

Advanced Features

Disabling Automatic registration
WCI registers all web applications by default. The portlet container analyzes the registered applications and initializes any portlets contained within them.
To prevent web applications from being automatically registered by the WCI component, set the gatein.wci.native.DisableRegistration context-param to true in the web.xml file of the application.
<!-- Disable the Native Application Registration -->
   <context-param>
    <param-name>gatein.wci.native.DisableRegistration</param-name>
    <param-value>true</param-value>
  </context-param>
Manual application deployment.
If you have disabled the automatic registration of your application in the first step, the portal container will not know about any of the portlets contained and will not be able to initialize them. WCI does have a servlet which can be used to manually register the web application. Since servlets can specify when they are deployed with regards to other servlets, we can use this to specify that the web application gets registered by WCI after another servlet has already been started. This means that the a servlet, for example the Spring servlet, can be initialized before any of the portlets.
Below is an example web.xml file configured to ensure the MyCustomServlet will be initialized before the webapp is registered by WCI:
<!-- Disable the Native Application Registration -->
   <context-param>
    <param-name>gatein.wci.native.DisableRegistration</param-name>
    <param-value>true</param-value>
   </context-param>
<!-- Register the Web Application Manually -->
   <servlet>
    <servlet-name>GateInServlet</servlet-name>
    <servlet-class>org.gatein.wci.api.GateInServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
   </servlet>
<!-- Custom Servlet which will be initalised before the webapp is registered in WCI -->
  <servlet>
    <servlet-name>MyCustomServlet</servlet-name>
    <servlet-class>my.custom.Servlet</servlet-class>
    <load-on-startup>0</load-on-startup>
  </servlet>
<!-- Servlet Mapping for the Manual Registration -->
  <servlet-mapping>
    <servlet-name>GateInServlet</servlet-name>
    <url-pattern>/gateinservlet</url-pattern>
  </servlet-mapping>

11.2. The Command Servlet

The CommandServlet is called by the portlet container for requests to particular portlets, it also includes some init code when the portal is launched. This servlet (org.gatein.wci.api.GateInServlet) is automatically added during the deployment of each portlet application and mapped to /gateinservlet.
This is equivalent to adding the following into web.xml.

Note

The servlet is already configured. This example is for information only.
<servlet>
  <servlet-name>GateInServlet</servlet-name>
  <servlet-class>org.gatein.wci.api.GateInServlet</servlet-class>
  <load-on-startup>0</load-on-startup>
</servlet>
  
<servlet-mapping>
  <servlet-name>GateInServlet</servlet-name>
  <url-pattern>/gateinservlet</url-pattern>
</servlet-mapping>
It is possible to filter on the GateInServlet by filtering the URL pattern used by the servlet mapping.
This example would create a servlet filter that calculates the time of execution of a portlet request.
The filter class:
package org.example;

import java.io.IOException;

import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class MyFilter implements javax.servlet.Filter {

  public void doFilter(ServletRequest request, ServletResponse response,
      FilterChain chain) throws IOException, ServletException
  {
    long beforeTime = System.currentTimeMillis();
    chain.doFilter(request, response);
    long afterTime = System.currentTimeMillis();
    System.out.println("Time to execute the portlet request (in ms): " + (afterTime - beforeTime));
  }

  public void init(FilterConfig config) throws ServletException
  {
  }

  public void destroy()
  {
  }

}
The Java EE web application configuration file (web.xml) of the portlet is the file on which we want to know the time to serve a portlet request.
As mentioned above nothing specific to Red Hat JBoss Portal needs to be included, only the URL pattern to set has to be known.
<?xml version="1.0"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.5">
        
  <filter>
    <filter-name>MyFilter</filter-name>
    <filter-class>org.example.MyFilter</filter-class>        
  </filter>

  <filter-mapping>
    <filter-name>MyFilter</filter-name>
    <url-pattern>/gateinservlet</url-pattern>
    <dispatcher>INCLUDE</dispatcher>  
  </filter-mapping>    
    
</web-app>

Note

It is important to set INCLUDE as dispatcher as the portal will always hit the GateInServlet through a request dispatcher. Without this, the filter will not be triggered, unless direct access to a resource (such as an image) is set.