Sample description
Most development environments consist of a testing server and a live (production) server. There may be a number of individual developer systems involved as well. Usually these testing and production systems are configured differently from the development systems. Examples of configuration settings that may change based on the environment include DataSource names, web service URLs, or the amount of error handling that you want to enable. Because of these variances, it can be difficult to make minor configuration changes to portlet wars without having to redeploy or configure a Designer to point to the deployed portlet war. This sample has been created to help facilitate minor configuration changes without having to redeploy the war or modify the deployed war.
The profiling capabilities of IBM
® WebSphere
® Portlet Factory allow you to change and restructure vast amounts of functionality in a portlet through two different mechanisms - the profile selection handler and the profile value setter. For each profile set in your model, you can configure your own profile selection handler and profile value setter classes. This sample leverages the custom classes to set profiles and profile values from a configuration file. By profiling key aspects of portlets and service provider models, it's possible to make portlet configuration changes on the fly, without having to use the Designer. Changing out datasource names, web service URLs, service provider models, or enabling error handling can be performed from a property file on the remote server.
- Profiling a model. Profiling key builder inputs and associating them with a configuration profile set allows their values to be changed by the property profiling sample. Portlets or provider models that share input values (wsdl urls, service provider model names, datasource names) should share a profile set that contains all of the configuration parameters, so that all the configuration values used throughout the application are handled consistently. Multiple profile sets can exist in a model, so you can use a separate profile set for other builder inputs in the model that are not related to configuration if you want to profile those also (e.g. for personalization in the Portal).
- Creating a Selection Handler. If a profile set contains a set of profiles that will be configured, a custom profile selection handler will need to be used. A selection handler config file needs to be created as well, that will map to the selection handler class. For this sample a selection handler config file WEB-INF/config/selection_handlers/PropertyFileSelectionHandler.xml has been included. The associated selection handler class, WEB-INF/work/source/com/bowstreet/samples/profiles/PropertyFileSelectionHandler, has also been included.
- Creating a Profile Value Setter class. Profile sets that only contain a Default profile can have their values explicitly set via a profile value setter class. A sample class, WEB-INF/work/source/com/bowstreet/samples/profiles/PropertyFileProfileValueSetter.java, has been provided. Once a profile set has been configured to use this custom class, the profile values will derive from an included property file.
- Creating custom property files. The custom profile handlers are driven from two property files. These files reside in WEB-INF/samples/property_file_profiling/config/.
If a property is found that matches up to a specific profile set, then the handler classes will update the profile with the value stored in the property file.
The sample models illustrate two ways of profiling from properties files:
Profile selection handler The
ProfiledDataProvider and
ProfiledErrorHandling models have corresponding profilesets that contain unique profile names. The profile names are driven by the property file profile selection hander. This selection handler reads in specific profile names from the
WEB-INF/samples/property_file_profiling/config/ProfileSelectionConfig.properties config file. Individual profile names can be assigned. In most cases this can be used where you have a predetermined set of options (profiles), that you would like to choose from.
Profile values setter The
ProfileValueExplicit model shows how specific builder inputs can be set from the properties file. In this case, the Base HTML page and Paging enablement can be changed on the server just by editing the properties file. This mode is useful when you want to configure values that may be custom (such as the path to a file name, or a remote server URL).
Notes on running the sample and prerequisites
- Import the attached zip file into your project using the Import WebSphere Portlet Factory Archive command.
- Open one of the models found in WEB-INF\models\samples\property_file_profiling and run it. These models will run out-of-box without any configuration required.
- Following the directions listed in each model, modify the associated property file values that are stored within WEB-INF\samples\property_file_profiling\config.
- Close the model, and run it again after making a change. The values will be picked up automatically.
Download
property_file_profiling.zip
Additional considerations
This sample shows two techniques for setting profile values from a properties file. Choosing which technique to use in your application depends on the nature of the values that you need to customize.
If the set of values is known ahead of time, and the values can be divided neatly into distinct profiles (e.g. Development config settings, Test Server config settings, Deployment config Settings), then using a custom profile selection class will work well. Create a profile set with the appropriate entries and add a named profile for each distinct set of values. Create a properties file that simply contains the name of the profile to use for each deployment environment. Create a profile selection handler that reads the properties file to determine which named profile to use.
If the set of potential values is not known ahead of time, or if you need the ability to change the values without having to redeploy the war, then using a custom value setter class is better suited to your needs. Create a profile set with the appropriate entries. It is not necessary to create individual named profiles. Create a properties file that contains a property to match each of the profile entries, and supply values for each of the properties that are appropriate for the deployment environment. Create a custom value setter class that reads the properties and supplies values for each profile entry.