Network Deployment (Distributed operating systems), v8.0 > End-to-end paths > Portlet applications

Task overview: Managing portlets

We can use this task to manage deployed portlet applications.

Before you begin this task, have a portlet application installed. See Install enterprise application files for additional information. We can complete the following steps to manage portlets.

Procedure

• Render a portlet.
  • Access a single portlet using Portlet Uniform Resource Locator (URL) addressability.
  • Access multiple portlets using Portlet aggregation using JSP.
  • Access portlets using Remote request dispatcher.

• Change the location of Portlet preferences. By default, portlet preferences for each portlet window are stored in a cookie. However, you can change the location of where to store portlet preferences.

• Disable URL addressability. By default, you can access a portlet through an Uniform Resource Locator (URL), however, you can disable this feature.
• Enable portlet fragment caching. Portlet fragment caching is disabled by default.

Example

An asynchronous bean method can use the connections that its creating Java EE component obtained using java:comp resource references.

• Use the portlet aggregation tag library
• Configure the extended portlet deployment descriptor to disable PortletServingServlet

Use the portlet aggregration tag library. We can use the aggregation tag library to aggregate multiple portlets to have multiple and different content on one page. The library can be used by every JSP file that has been included by a servlet.

To use the portlet aggregation tag library, declare the tag-lib at the top of the JSP file using, <%@ taglib uri="http://ibm.com/portlet/aggregation" prefix="portlet" %>, as in the following example. The following JSP file example shows how to aggregate portlets on one page. We can use the aggregation tag library to aggregate multiple portlets to have multiple and different content on one page. The library can be used by every JSP file that has been included by a servlet.

class GoodAsynchBean
{
 DataSource ds;
 public GoodAsynchBean()
  throws NamingException
 {
  // ok to cache a connection factory or datasource
  // as class instance data.
  InitialContext ic = new InitialContext();
  // it is assumed that the created Java EE component has this   // resource reference defined in its deployment descriptor.
  ds = (DataSource)ic.lookup("java:comp/env/jdbc/myDataSource");
 }
 // When the asynchronous bean method is called, get a connection,  //  use it, then close it.
 void anEventListener()
 {
  Connection c = null;
  try
  {
   c = ds.getConnection();
   // use the connection now...
  }
  finally
  {
   if(c != null) c.close();
  }
 }
}

The following example illustrates an asynchronous bean that uses connections incorrectly:

class BadAsynchBean
{
 DataSource ds;
 // Do not do this. We cannot cache connections across asynch method calls.
 Connection c;

 public BadAsynchBean()
  throws NamingException
 {
  // ok to cache a connection factory or datasource as   // class instance data.
  InitialContext ic = new InitialContext();
  ds = (DataSource)ic.lookup("java:comp/env/jdbc/myDataSource");
  // here, you broke the rules...
  c = ds.getConnection();
 }
 // Now when the asynch method is called, illegally use the cached connection
 // and you likely see J2C related exceptions at run time.
 // close it.
 void someAsynchMethod()
 {
  // use the connection now...
 }
}

Configure the extended portlet deployment descriptor to disable PortletServingServlet. Portlet URL serving supports direct access to all functions and states of a portlet by creating the appropriate URLs. In a production setup where the portlet is served through an enterprise portal application that applies its own access control, is considered a security risk. By setting the portletServingEnabled property to false, an administrator can ensure that a sensitive portlet is never accessed by direct URL serving.

Extensions for the portlet deployment descriptor are defined within a file called ibm-portlet-ext.xmi. This deployment descriptor is an optional descriptor that you can use to configure WebSphere extensions for the portlet application and its portlets. For example, you can disable the PortletServingServlet servlet for the portlet application in the extended portlet deployment descriptor.

The ibm-portlet-ext.xmi extension file is loaded during application startup. If there are no extension files specified with this setting, the default values of the portlet container are used.

The default for the portletServingEnabled attribute is true. The following is an example of how to configure the application so that a PortletServingServlet servlet is not created for any portlet on the portlet application.

<?xml version="1.0" encoding="UTF-8"?>
<portletappext:PortletApplicationExtension xmi:version="1.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:portletappext="portletapplicationext.xmi"
    xmlns:portletapplication="portletapplication.xmi"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmi:id="PortletApp_ID_Ext"
    portletServingEnabled="false">

<portletappext:portletApplication href="WEB-INF/portlet.xml#myPortletApp"/>
</portletappext:PortletApplicationExtension> 

Related

Portlets
Portlet container
Portlet container settings
Portlet aggregation using JSP
Portlet Uniform Resource Locator (URL) addressability
Portlet preferences
Example: Configuring the extended portlet deployment descriptor to disable PortletServingServlet
Convert portlet fragments to an HTML document
Portlet container custom properties
Portlet and PortletApplication MBeans
Portlet URL security
View deployment descriptors

+

Search Tips   |   Advanced Search