This section describes the portal lifecycle from the application server start to its stop and how requests are handled.
Application Server start and stop
A portal instance is simply a web application deployed as a WAR in an application server. Portlets are also part of an enhanced WAR called a portlet application.
GateIn 3.5 does not require any particular setup for your portlet in most common scenarios and the web.xml
file can remain without any GateIn 3.5 specific configuration.
During deployment, GateIn 3.5 will automatically and transparently 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.
Advanced WCI Registration
eXo Platform 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, especially Spring based portlets, may have requirements that specific servlets be started before any portlets are initialized. Although portlets and servlet initialization order are meant to be independent of each other, eXo Platform does have a way to get around these limitations imposed by these specific third party applications.
As a workaround to this issue, two new, advanced features have been integrated into the WCI component;
Advanced features:
Disabling automatic registration
By default WCI will register all web applications and the portlet container will then analyze the registered applications and initialize any portlets contained. If you do not wish for your web application to be automatically registered by the WCI component, you can disable this feature. By disabling this feature, you can prevent the automatic initialization of the portlet and specify later when you want it to be initialized.
This is done by setting the
gatein.wci.native.DisableRegistration
context-param to
true in the
web.xml
file of the application, as shown below:
<!-- 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 initialized 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>
The servlet is the main entry point for incoming requests, it also includes some init codes when the portal is launched. This servlet (org.gatein.wci.command.CommandServlet) is automatically added during deployment and mapped to /tomcatgateinservlet.
This is equivalent to adding the following to web.xml
.
As the servlet is already configured, this example only aims at providing information.
<servlet>
<servlet-name>TomcatGateInServlet</servlet-name>
<servlet-class>org.gatein.wci.command.CommandServlet</servlet-class>
<load-on-startup>0</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>TomcatGateInServlet</servlet-name>
<url-pattern>/tomcatgateinservlet</url-pattern>
</servlet-mapping>
It is possible to filter on the CommandServlet by filtering the URL pattern used by the Servlet mapping.
The example below 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 on which we want to know the time to serve a portlet request. As mentioned above, GateIn 3.5 does not require anything special 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>/tomcatgateinservlet</url-pattern>
<dispatcher>INCLUDE</dispatcher>
</filter-mapping>
</web-app>
It is important to set INCLUDE as a dispatcher as the portal always hits the CommandServlet through a request dispatcher. Without this, the filter will not be triggered, unless the direct access to a resource, such as an image.
See also