Creating a simple portlet
View the basic steps for creating a simple portlet, that include writing the portlet code, compiling java source, creating the JAR file, writing the portlet descriptors, setting up the WAR file directory structure, and packaging and deploying portlets.
Before you begin developing portlets, set up an environment that makes the tasks of writing, compiling, and testing portlets easier. Rational® Application Developer includes a test environment that you can use to run and debug your portlets without having to manually deploy them to the server. You can set up the run time environment for debugging portlets on the local development machine or on a remote server. Refer to the documentation for Rational Application Developer for complete setup instructions.
Writing the portlet code
If you are familiar with writing to the IBM portlet API, here are some of the key differences between this standard API example and the corresponding Figure 6.
API element | IBM portlet API | Java Portlet Specification |
---|---|---|
import statements | org.apache.jetspeed.portlet | javax.portlet |
Portlet class | PortletAdapter | GenericPortlet which also can throw a PortletException |
Request object | PortletRequest | RenderRequest |
Response object | PortletResponse | RenderResponse |
Also notice that the content type must be set in the response.
Compiling Java source
- Linux: ./setupcmdLine.sh
- IBM i: setupcmdLine.sh
- Windows: setupcmdLine.bat
- Standard portlets
- These files are located in the directory PortalServer_root/doc/compile. The JavaDocs are available via http://www-10.lotus.com/ldd/portalwiki.nsf/xpViewCategories.xsp?lookupName=IBM%20WebSphere%20Portal%207%20API%20and%20SPI%20Reference.
Table 2. Description of the jar files for the standard portlets Jar file Purpose portletapi_20.jar This file complies with the Java Portlet Specification Version 2.0. public_api.jar Use this file if you use services from the Public API javadoc package. public_api.jar + public_spi.jar Use this file if you use services from the Public SPI javadoc package. - IBM portlets
Table 3. Description of the jar files for the IBM portlets Jar file Purpose wp.pe.api.legacy.jar IBM portlet API wp.portletservices.api.legacy.jar Portlet services wp.pe.rt.api.jar Portlet menus
appserver\java\bin\javac -classpath %WAS_CLASSPATH%;path_to\portletapi_20.jar
com.ibm.wps.samples.jsr.HelloWorld.java
appserver\java\bin\javac -classpath %WAS_CLASSPATH%;path_to\portletapi_20.jar
com.ibm.wps.samples.v4.HelloWorld.java
- Loading classes for portlets
WebSphere Portal Express classloading follows the WebSphere Application Server hierarchy for classpaths and search orders. A particular class loader can reference other classes as long as the other classes can be loaded by the same class loader or any of its ancestors, but not its children. The graphic illustrates where WebSphere Portal Express and portlet applications fit into the classloading hierarchy.
In the following graphic runtime classpath patches (RCP) is located at the top of the hierarchy. Runtime classpath (RP) branches from runtime classpath patches. Runtime extensions (RE) branches from runtime classpath, and application extensions (AEX) branch from runtime extensions. Application class loaders (AC1), application class loaders (AC2), and application class loaders (AC3) are portlet applications that branch from application extensions.
As illustrated, WebSphere Portal Express is an application extension (AEX) under WebSphere Application Server. Consequently, the WebSphere Portal Express core classes are in the classpath PortalServer_root/shared/app. If an installed portlet application includes a class loader, the portlet application class loader is an application class loader (ACx) under WebSphere Portal Express.
If you suspect a classloading problem, ensure that the required classes are in the appropriate classpath according to the classloading hierarchy.
Creating the JAR file
Next, the portlet must be packaged in the JAR file format. To create a JAR file with the name HelloWorld.jar, enter the following command:
jar -cf HelloWorld.jar HelloWorld.class
Refer to the JDK documentation for more information about the JAR command.
Writing the portlet descriptors
The following samples can be packaged with the Hello World portlet.
- Web application deployment descriptor for standard portlets:
- According to the Java Portlet Specification, only Web resources
that are not portlets should be declared in the web.xml. However,
the following properties should be set to correspond to the portlet
descriptor:
- <description/>
describes the portlet application.
- <display-name/>
indicates the portlet application name.
- <security-role/>
indicates the portlet application security role mapping. Omit this tag if the portlet does not use this feature.
If you are familiar with the web.xml for IBM portlets, the key difference between this example and the corresponding Figure 7 is the required <servlet/> element in the web.xml for IBM portlets.
- <description/>
- Standard portlet deployment descriptor:
- The following shows the minimum elements required for the standard portlet deployment descriptor.
There are number of differences between the elements in this example and the corresponding Figure 8. In addition, the standard portlet descriptor is defined by an XML schema and does not require a DTD.
Setting up the WAR file directory structure
Before you package your portlet, the class files and resources must be arranged in the WAR file directory structure described here. A portlet application exists as a structured hierarchy of directories.
- /
- The root directory of the portlet file structure.
- /images
- Location for any images the required by the portlet.
- /WEB-INF
- Location for all protected resources. The /WEB-INF directory stores the portlet descriptor document and all of the
run time executable JAR files and classes that the packaged portlet
requires.
The portlet information directory is not part of the public document tree of the application. Files that reside in /WEB-INF are not served directly to a client.
- /WEB-INF/lib
- Location for storing portlet JAR files.
- /WEB-INF/jsp
- Location for JSP files. This is a suggested path name. Your JSPs can be packaged in any location. JSPs that are included inside the portlet markup should be placed under the /WEB-INF directory. You should only place them outside the /WEB-INF directory if you create direct links to them.
- /WEB-INF/classes
- Location for portlet class files. Individual class files should be stored in a directory structure within /WEB-INF/classes that reflects the class package. For example, the class HelloWorld.class, in package com.ibm.wps.samples, would be stored in /WEB-INF/classes/com/ibm/wps/samples/HelloWorld.class.
- /META-INF
- Location for the manifest file, manifest.mf and the Java 2 security file, was.policy (if present). The manifest is in the standard JAR file format as defined by the Java 1.3 specification. The Java 2 security policy file is used to allow a portlet to perform operations that might be restricted if Java 2 security is enabled. The contents of the /META-INF directory is not served to clients.
Packaging and deploying portlets
To deploy a portlet and run it on the server, it must be packaged in the form of a Web application ARchive or WAR file. The WAR file format contains the Java classes and resources that make up one or more portlets in a portlet application. The resources can be images, JSP files, Writing the portlet descriptors, and property files containing translated message text. Packaging portlet classes, resources, and descriptive information in a single file makes distribution and deployment of portlets easier.
WebSphere Portal Express includes an administrative portlet for installing, uninstalling, and updating portlets. Portlets contained in WAR files have the advantage of being dynamically downloaded and installed. The portal administrator can download a WAR file from the Internet and then use the portal administration interface to install the portlet to WebSphere Portal Express. After installation, the portlet is ready for use and does not require the server to be restarted. To package your portlet in a WAR file, you can use the JAR utility to package the portlet into a WAR file.
- Packaging a portlet and resources into a WAR file
Any JAR utility may be used to build a WAR file. Below are examples of how to use the JAR utility provided by WebSphere Application Server.
- To create a WAR file with the name HelloWorld.war and include all of the files in the /WEB-INF and /images directories:
jar -cf HelloWorld.war images WEB-INF
- To update an existing WAR file, HelloWorld.war with a revised portlet descriptor:
jar -uf HelloWorld.war WEB-INF/portlet.xml
- To extract the portlet descriptor from the WAR file, HelloWorld.war :
jar -xf HelloWorld.war WEB-INF/portlet.xml
- To extract all files from an existing WAR file, HelloWorld.war:
jar -xf HelloWorld.war
After the WAR file is created, it can be installed to WebSphere Portal Express as described in Portal administration portlets.
- To create a WAR file with the name HelloWorld.war and include all of the files in the /WEB-INF and /images directories:
- Preparing the portlet application for installation
To facilitate deployment of portlet applications and complex portlets, you can provide a portlet configuration file that can be invoked by the XML configuration interface (XMLAccess). The XML configuration interface allows the portlet developer to specify places, pages, themes, skins, supported markups and clients, and other settings for a portlet application. This is especially useful for portlets that use messaging because these portlets have to be placed on the same page. For more information, see The XML configuration interface. There is also some helpful information about XMLAccess in the IBM WebSphere Portal Zone.
When constructing XMLAccess scripts for use in installing standard portlets, use the following values:- uid attribute for the <web-app> element:
Use the uid attribute of the <portlet-app/> subelement with a .webmod suffix. As described subsequently in this topic, the uid attribute of the <portlet-app/> subelement is dependent on the presence of the id attribute of the <portlet-app/> element from the portlet.xml.
- uid attribute for the <portlet-app> element:
Use the id attribute of the <portlet-app/> element from the portlet.xml. If this value has not been specified, specify the WAR file name of the portlet application in its place. For portlet updates, the WAR file name must be the original name of the WAR file used to install the portlet application. That is, the WAR file name can be changed, but the uid must indicate the original uid used during portlet installation.
- name attribute for the <portlet> element:
Use the content of the <portlet-name/> element from the portlet.xml.
- referenceid attribute of the <servlet>
element:
Use the content of the <portlet-name/> element from the portlet.xml appended with the .servlet suffix.
For example, a portlet application might use a portlet descriptor as follows:In this example, there is no id attribute provided on the <portlet-app/> element. Therefore, the <portlet-app/> element of the XMLAccess script would use the WAR file name, as follows:
- uid attribute for the <web-app> element:
IBM portlet API examples for Hello World
As described in Deployment descriptors, the href attribute of the <portlet/> element references the servlet ID from Web deployment descriptor.