Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows
Manage portlets and portlet applications
Before you make portlets or portlet applications available to your users by putting them on portal pages, you need to prepare them. This topic gives an overview of tasks that you might perform to prepare the portlets and portlet applications. This includes installing, deploying, and configuring portlets and applications.
You can further work with portlets by using the administration portlets that are available under...
Main Menu | Administration | Portlet Management
After you have completed preparing your portlets, you can make them available for your users.
- Web modules, portlet applications, and portlets
- Installing portlets
- Activating and deactivating portlet applications or portlets
- Configuring portlet application or portlet parameters
- Modifying portlet settings
- Copying portlet applications or portlets
- Updating portlet applications
- Deleting or uninstalling portlet applications
- Providing and consuming portlets by using WSRP
- Deploying J2EE resources with portlet application WAR files
Web modules, portlet applications, and portlets
A Web module represents a Web application. It is used to assemble servlets and JSP files as well as static content, such as HTML pages, into a single deployable unit. Web modules are stored in Web ARchive (WAR) files, which are standard Java archive files. The standard file extension for WAR files is .war.
A Web module can contain one or more portlet applications, servlets, JavaServer Pages (JSP) files, and other files. A deployment descriptor, stored in an Extensible Markup Language (XML) file, declares the contents of the modules, information about the structure and external dependencies, and a description of how the components are to be used at run-time.
Portlet applications are created implicitly when a WAR file is deployed. The portlet application holds one or more related portlets that come packaged in the same installation file. These portlets can share resources and send messages among themselves to communicate events. A portlet application may consist of a single portlet or multiple portlets. An example of a single portlet application is the WorldClock portlet application, which contains a single portlet named World Clock Portlet.
An example of a portlet application with multiple portlets is Portlet Manager Application, which contains Manage Web Modules, Manage Applications, and Manage Portlets. For additional information on working with WAR files, see the information center for WebSphere Application Server.
You can add portlets to a running system at any time. After installation, the new portlets are immediately available to administrative users. They can assign the appropriate user roles to the desired groups and users so that these can access and use the portlets. Once available, the portlets can be selected for display on the portal pages of users and can be edited as appropriate.
Identification information of WAR files is stored in a database for easy deployment in complex server environments with multiple portal servers. By allowing all files associated with a portlet to be packed into a single file, distribution and deployment of new portlets is made easier. Portlets can be distributed in WAR file format through Web sites and other means.
This section has the following topics:
Install portlets
IBM® WebSphere® Portal Express includes Manage Web Modules on the portal page of Portal Administration for easy installation of portlets and portlet applications. An administrator must have the Manager role on the portal to install portlets. If the Manager role on the portal exists, the administrator selects a WAR file that is made available to the running system after installation. Each WAR file includes descriptive information about the portlet, which is placed in a database that can be queried by other portal components. During installation, Application Server unpacks the WAR file and places the portlet classes and resources in a file system.
As Windows limits the maximum path length to 260 characters, the name of the WAR file must be 25 characters or less.
Installing a WAR file with a name that is more than 25 characters will result in an error.
During the installation, the portlet state is set to active, and a new rule is automatically added to Access Control that defines the user who installed the portlet as the owner, granting management access for that portlet. The user must assign the appropriate user roles to the desired users and groups so that these can access and use that portlet.
You cannot install a portlet more than once. If you want two instances of a portlet application or portlet, use the copy command to create a second instance.
Activating and deactivating portlet applications or portlets
By default, portlet applications and portlets are set to an active state after installation. Pages also have an active and inactive state. You can deactivate a resource to prevent users from accessing it without changing their user roles. When a portlet application or portlet is in the active state, portal users with appropriate access can include it on their personal pages and customize it. Users that have active references to those inactive portlets on a portal page will see a message stating that the portlet is temporarily disabled. If you begin working on a portlet, WebSphere Portal Express automatically changes the state to deactivated. After completing work on the resource, remember to activate it so that others with appropriate permissions can use it.
You can toggle portlet application or portlet states to active or inactive by using the portal XML configuration interface. For details about how to do this refer to Working with the XML configuration interface and Reference: Sample XML configuration files.
Configure portlet application or portlet parameters
Many portlet applications and portlets have associated configuration parameters that must be changed after deployment. Manage Applications and Manage Portlets allow you to modify configuration parameters. The original configuration is determined by settings in the portlet.xml deployment descriptor file. Configuration changes apply to each specific instance of the portlet. WebSphere Portal Express does not validate configuration modification to portlet applications.
For more information about the configuration of portlets and applications refer to the following sources:
- For additional information about portlet configuration from a portlet development point of view refer to Portlet development basics and Preference layers and portlet modes.
- Some of the portlet parameters can be configured in the portlets themselves by using the portlet modes. For overview information about portlet modes refer to Modifying portlet settings. For more detailed information about portlet modes refer to Configuration levels for portlets.
- For instructions about the tasks and detailed steps for changing configuration values refer to the Manage Applications or Manage Portlets helps.
Modifying portlet settings
A portlet is initially displayed in the View mode. A user can apply customizations to individual, selected, or all instances of the portlet by leaving the View mode and entering into the Personalize, Edit Shared Settings, or Configure mode as appropriate. To access these other modes, hover over the portlet title bar, click 
to display the portlet menu, and select the appropriate mode.
Once you leave the View mode by selecting another portlet mode, click Back from the portlet menu to return to the View mode. You must return to the View mode before changing to another mode.
>
Personalize: Updates change the look of the portlet only for the user who makes the updates. In order for a user to have access to personalize settings, they must be granted at least Privileged User role on the page and Privileged User role on the corresponding Portlet Definition. This is available for standard portlets and IBM portlets. Edit Shared Settings: Updates change the default look of the portlet on a specific page. All users see the change when they access that page. In other words, all (the particular) portlet instances on a page are modified, but not all instances of that portlet on every page. If you want the changes to appear on every page that portlet appears, modify the settings on each page. In order for a user to have access to edit shared settings they must be granted at least Editor role on the page and Editor role on the corresponding Portlet definition. This is available for standard portlets and IBM portlets. Configure: Updates change the default look of a portlet for all portlet instances. All users see the portlet changes on all pages that portlet is available. A user needs to have at least Manager role on portlet definition to have access to configure a portlet.
It depends on the portlet which selection options are available in the portlet menu.
Copying portlet applications or portlets
- Portlet Applications
-
With Manage Portlet Application, you can copy a portlet application.
The copy should be given a new name. A copy of a portlet application includes some or all of the portlets from the original portlet application. If you want additional instances of a portlet application, you should make a copy.
When a portlet application is copied, the portlet data and the portlet application data are copied, but the copied portlet application uses the same resources as the original portlet application. When a copied portlet application is copied, the new portlet application also uses the same resources as the original portlet application. An example of portlet data is the portlet configuration parameters needed for a particular instance of a portlet An example of a portlet resource is an image that the portlet displays in the user interface. While the portlet configuration parameter is associated with each instance of the portlet, all instances of the portlet use the same image.
Only portlets in the copied portlet application will be in the new portlet application.
For instance, if the copied portlet application contains four portlets and the original contains five portlets, only the four portlets are copied to the new portlet application.
Copying can be useful when different portlet configuration parameters are required for different instances of a portlet.
A copy of the portlet application can be used to configure the portlet instance for each portlet application. For example, the administrator might want to have multiple RSS portlet applications. Each copied application would have a different URL, accessing a different content channel, configured for its RSSPortlet.
- Portlets
-
With Manage Portlets, you can copy a portlet. You should give the copy a new name. If a portlet is copied or a remote portlet is integrated, a new portlet application is created by the portal that holds the new portlet.
When a portlet is copied, the portlet data is copied, but the copied portlet uses the same resources as the original portlet. When a copied portlet is copied, the new portlet also uses the same resources as the original portlet. An example of portlet data is the portlet configuration parameters needed for a particular instance of a portlet An example of a portlet resource is an image that the portlet displays in the user interface. While the portlet configuration parameter is associated with each instance of the portlet, all instances of the portlet use the same image.
Updating portlet applications
Update a portlet application by updating the WAR file in Manage Web Modules. The newer version of the resource in the WAR file updates the existing portlet application, without breaking the links between user data and the resource.
User-specific settings for portlets within the updated resource remain unchanged.
Before a selected Web module is updated, WebSphere Portal Express checks for an identical resource name in the selected WAR file. If the name of the selected object and the object name in the deployment descriptor of the WAR file do not match, the update is not performed, and a message is displayed.
When a Web module is updated, WebSphere Application Server removes the existing files and installs the updated application in the same directory.
Updating the configuration parameters from the portlet deployment descriptor is controlled by the setting of update.portlet.preserves.config.settings in the DeploymentService. New parameters that are introduced by the updated Web module are always added to the Web module. However, changed parameters are updated only if the following value is set:
update.portlet.preserves.config.settings=false
By default, this setting is true, preventing configuration parameters in the updated portlet deployment descriptor from updating existing parameters.
Deleting or uninstalling portlet applications
Web modules can be deleted or uninstalled in Manage Web Modules and portlet applications can be deleted using Manage Applications. Portlets can be deleted using Manage Portlets. After selecting an object for deletion, the system waits until all outstanding requests for the portlet application or portlet have been completed and then removes all related files and resources from the portal server. Before removing a portlet application, first delete all of its copied portlet applications. If you have the portlet WAR file, you may reinstall the portlet components after deleting it from the system by updating the WAR file in Manage Web Modules. You can reinstall the deleted portlet after ensuring all portlet applications installed in the portlet WAR file have been removed and that the WAR file has been uninstalled.
Do not delete any Administration portlets.
Providing and consuming portlets by using WSRP
WebSphere Portal Express supports the Web Services for Remote Portlets (WSRP) standard. Producers can provide portlets as WSRP services for Consumers who integrate and use them.
Related information
- Disabling anchors in portlet URLs
When you access a portlet in WebSphere Portal Express, the portal appends an anchor to the portlet URL. In the case of several portlets arranged vertically on a page, this appended anchor forces the browser to scroll down to the portlet rather than display the top of the page. You might prefer to have the top of the page displayed, even if the link that was clicked points to a portlet which is placed further down on the page. To achieve this, you can disable the anchors.
- Configuration levels for portlets
Many portlets provide separate views that allow configuration of the portlet. These view types are also called portlet modes. Depending on how they are programmed, the portlets can be configured on different levels. - Configuring portlets to support shared configuration
This topic describes how you set up portlets that do not support the edit_defaults portlet mode for shared configuration. - Deploying J2EE resources with portlet application WAR files
This topic describes how you can manually predeploy portlet application WAR files using the WebSphere Application Server Administration console and later register them into WebSphere Portal Express, together with other J2EE resources and artifacts.