IBM Support

JSF Portlet Development Migration topics: Tips and Suggestions

Technote (FAQ)


Question

Is there are list of JSF Portlet Migration tips and suggestions?

Cause

The purpose of this technote is to help answer the following questions:

  1. During planning for migrating WebSphere Portal Server Server v5.1.x, v6.0.x or WebSphere Application Server v5.1.x and WebSphere Application Server v6.1.x applications to WebSphere Portal Server v6.1.x and/or WebSphere Application Server v7.0.x, what are the key changes and concerns to be aware of?

  2. For a JavaServer Faces (JSF) portlet application, higher memory consumption is reported. Is this an expected behavior or as an application developer, are you required to take care of certain aspects of JSF Portlet programming model?

Answer

Migration Questions:

Question:

Which WebSphere Portal Servers are available for each version of Rational Application Developer for WebSphere Software?

Answer:

Rational Application Developer for WebSphere Software v6.x provided and supported WebSphere Portal Server v5.0.x and WebSphere Portal Server v5.1.x.

Rational Application Developer for WebSphere Software v7.0.x provided and supported WebSphere Portal Server v6.0.x and v5.1.x. As of v7.0.0.7, an option was made available to allow publishing of Portlets to a standalone WebSphere Portal Server v6.1 server.

Rational Application Developer for WebSphere Software v7.5.x provided and supported WebSphere Portal Server v6.0.x and WebSphere Portal Server v6.1.x. This includes WebSphere Portal Server v6.1.x installed on top of a WebSphere Application Server v7.0.x server.

See the following technotes for details for preparing such a server:


Question:

What are the JSF versions provided in each Rational Application Developer for WebSphere Software?

Answer:

Rational Application Developer for WebSphere Software v7.0.x provides JSF 1.1.x while Rational Application Developer for WebSphere Software v7.5 provides JSF 1.2.x

JSR168 portlets are supported with a dependency of the IBM Portlet bridge provided in Rational Application Developer for WebSphere Software.

JSF286 portlets can be created in Rational Application Developer for WebSphere Software v7.5.x but currently JSF 286 Events, Render Params and other advanced features are not supported in the IBM Portletbridge.

See the following two technotes about IBM Portlets and backwards compatibility:


Question:

What JSF versions are provided in the WebSphere Portal server?

Answer:

In WebSphere Portal Server v5.1.x, the portlets that are created contained the IBM JSF jars, the portletbridge and the JSF runtime jar files.

As of WebSphere Portal Server v6.0 which contained WebSphere Application Server v6.0, the JSF implementation runtime jars were available on the server. Therefore portlets that were created targeting WebSphere Portal Server v6.0 and above only contained the IBM JSF jars and the IBM Portletbridge jars. The IBM JSF jars are called the JWL (JSF Widget Library)

The version of the JSF implementation jars depended on the WebSphere Application Server server that the WebSphere Portal Server server was installed on top of.

WebSphere Portal Server v6.0/WebSphere Application Server v6.0 contains JSF 1.0.

WebSphere Portal Server v6.1/WebSphere Application Server v6.1 contains JSF 1.1.

WebSphere Portal Server v6.1/WebSphere Application Server v7.0 contains JSF 1.2.

If migrating to a WebSphere Portal Server v6.1 environment that uses WebSphere Application Server v7.0, be aware of the changes that have occurred in JSF 1.2.

Question:

How do you ensure you have migrated and updated my JSF jar files in my portlets?

Answer:

While migrating from Rational Application Developer for WebSphere Software v6.0.x to v7.0.x or v6.1, be sure to review the following technote to ensure the portlet has the newer jar files and code changes: http://www-01.ibm.com/support/docview.wss?uid=swg21286048

Note: Review the Rational Application Developer for WebSphere Software InfoCenter on the topic of Updating Faces runtime resources for portlet projects from V6.0.x for additional information: http://publib.boulder.ibm.com/infocenter/radhelp/v7r0m0/index.jsp?topic=/com.ibm.etools.rad.migration.doc/topics/tmgv6portletjsfto601.html

Similar steps can be applied for Rational Application Developer for WebSphere Software v7.5.

Question:

How do you determine what version of the IBM JSF jars and portletbridge do you have?

Answer:

Generally always allow Rational Application Developer for WebSphere Software to update your JSF jars when prompted to be upgraded to the latest version.

Note: If IBM Support has provided you with specific set of JAR files, clarify with Support which version of Rational Application Developer for WebSphere Software would contain the updates in the JAR files received and only allow Rational Application Developer for WebSphere Software to upgrade the JAR files once the indicated Rational Application Developer for WebSphere Software update levels have been applied. During this time, do not upgrade the JAR files.

As of Rational Application Developer for WebSphere Software v7.0.0.6, the manifest.mf file contained in each of the JAR files began to contain a version number to help identify the version of Rational Application Developer for WebSphere Software that provided the jar file.

Here is a list that corresponds to the Rational Application Developer for WebSphere Software version that provides the jsf-ibm.jar versions:

JWL version
Rational Application Developer for WebSphere Software version
3.0.8
7.0.0.6
3.0.9
7.0.0.7
3.0.11
7.0.0.8
3.0.12
7.0.0.9
3.0.13
7.0.0.10
3.0.14
7.0.0.11
3.0.10
7.5
3.1
7.5.1
3.1.1
7.5.2
3.1.2
7.5.3
3.1.3
7.5.4
3.1.4
7.5.5
3.1.5
7.5.5.1
3.1.6
7.5.5.2

Here is a list that corresponds to the Rational Application Developer for WebSphere Software version that provides the jsf-portletbridge.jar versions:

PortletBridge version
Rational Application Developer for WebSphere Software version
3.0.8
7.0.0.6
3.0.9
7.0.0.7
3.0.11
7.0.0.8
3.0.12
7.0.0.9
3.0.13
7.0.0.10
3.0.14
7.0.0.11
3.0.10
7.5
3.1
7.5.1
3.1.1
7.5.2
3.1.2
7.5.3
3.1.3
7.5.4
3.1.3
7.5.5
3.1.3
7.5.5.1
3.1.?
7.5.5.2

Question:

How do you migrate my WebSphere Portal Server Projects?

Answer:

Technote on WebSphere Portal Server Project Migration:

http://www-01.ibm.com/support/docview.wss?uid=swg21380006


Performance tuning tips:

This section describes some of the topics related to the use of JSF and the capabilities provided with the IBM JSF Portlet Bridge that a developer should be aware of, to optimize the design of an application with regard to memory consumption vs. application behavior.

Note: In IBM Rational Application DeveloperV6.x, JSF Portlet Bridge is available under the lib folder of an application as a jsf-portlet.jar, and as a jsf-portletbridge.jar in IBM Rational Application Developer V7.x, and later.

Tip: In general, upgrade to the latest version of the IBM JSF jars when possible when addressing any performance related problems.

  1. Portlet Render Parameters: com.ibm.faces.portlet.USE_RENDER_PARAMETERS

    This context parameter has been introduced for IBM WebSphere Portal V6.1 and is available in the portlet bridge (jsf-portletbridge.jar) from IBM Rational Application Developer V7.0.0.7, and later.
  2. Use of Multiple Action Execution (wps.multiple.action.execution)
    • Description: This is a portlet initialization parameter that can be set in the portlet’s deployment descriptor (that is, portlet.xml). This feature is used by IBM WebSphere Portal to stop processing the same Action request twice (for example, browser Back button feature). If this protection feature is left on (wps.multiple.action.execution=true), WebSphere Portal would treat a repeated Action URL as a Render URL with no repetition of portlet action, rather portlet would just be rendered. This is achieved by storing executed Action results and state in a session to prevent the multiple actions.

      JSF portlets may utilize large render parameters that are stored in portlet action results, so using the multiple action protection features with this storage of action results can cause in substantial memory consumption.

      Tip: To avoid high memory consumption, additional portal configuration settings that have multiple Action execution and result caching enabled can be used while capping the memory utilization. These can be used to specify a cache size boundary for Action ID keys and result state values.

      These are:
      • Setting: wps.multiple.action.cache.bound.enabled
        Values: true|false (default = false)
      • Setting: wps.multiple.action.cache.key.maxsize
        Values: int >= 1 (default = 20) (Must be larger than wps.multiple.action.cache.value.maxsize)
      • Setting: wps.multiple.action.cache.value.maxsize
        Values: int >= 1 (default = 5)


        A typical setting would be:

        wps.multiple.action.cache.bound.enabled=true
        wps.multiple.action.cache.key.maxsize=40
        wps.multiple.action.cache.value.maxsize=10
    • wps.multiple.action.cache.key.maxsize stores executed Action IDs of last 40 entries, thus preventing multiple execution (say when using Back button). This data is usually of few bytes, so setting a higher value doesn’t utilize high memory.

    • wps.multiple.action.cache.value.maxsize stores the Action result state of the last 10 entries and will correctly show the result of past executed Actions (say in case of Back button). It is usually a large data, and along with JSF Render Parameters it can grow to several KBs per entry, resulting in high memory consumption.

      These settings are available in IBM WebSphere Portal V6.1.0.2 thru APAR PK82601 and can be applied using IBM WebSphere Application Server admin console:

      WebSphere Application Server admin console > Resource Environment Providers > WP ConfigService

  3. Key Manager (keymanager.lru.size)
    • Description: This is a portal server side configuration parameter.

      The browser history expiration limit can be controlled by setting the value of this property to an integer value in the StateManagerService. From IBM WebSphere Portal infocenter:

      Use this parameter to specify the history expiration limit of portal pages visited by users. This determines how far backwards users can at least navigate in the recent history of portal pages that they visited. The number that you specify defines the minimum number of different pages selected by the user after which the portal can discard the render parameters of a page. (The decision whether the render parameters of the page are actually discarded depends on the expiration policy of the internal cache that stores the render parameters of those pages.) If the user returns to a page after visiting the specified number of other pages and if the render parameters of that page have expired, the portal displays that page in its default state.

      The description above indicates that this affects navigation between portal pages and not portlets.

      Tip: If this parameter is enabled, number of Render Parameters in a session can somewhat be controlled. A typical setting would be: keymanager.lru.size = 3

  4. Make use of Navigation Rules

    In case rendering of same page is required, developers should follow the navigation rules. Same page rendering can happen in the following cases:
    • If an Action returns NULL or an empty String, JSF will re-render the same page using the current JSF tree state.
    • In some cases staying on the same page cannot be avoided, for example, a form is submitted and it has validation errors.

      In portal due to the split of request into Action phase and Render phase, staying on the same page also needs to pass the tree state to the Render phase. Irrespective of approach used, it is an overhead for performance and memory usage.

      Tip: If one’s intent is to display the same page with different content, then a navigation rule should be set up to navigate to the page. In this case no state is sent to the Render phase.

Question

Are there any further tips that can be incorporated in general for JSF Portlets?

Answer

Yes, following tips would probably help -

  1. Use the most recent version of JSF Portlet Bridge

    It is recommended to use the latest version of JSF Portlet bridge jar (jsf-portletbridge.jar). This jar is packaged and shipped with IBM Rational Application Developer. So, users are advised to update their IBM Rational Application Developer installations to the latest fix packs.


  2. Eliminate unnecessary and excessive per-user session memory usage

    (For example, <t:saveState> from the Tomahawk library)

    Excessive use of the Tomahawk <t:saveState> tag increases the size of JSF view state information and should be removed from the code. The tag provides an easy-to-use capability that masks the complexity of per-user memory management (also known as session management) without solving the inherent problems of session management, such as:
    • storing redundant copies of application data within session memory thru t: saveState tags
    • failing to delete application data from session memory when appropriate

      Even a slight session management problems become significant causes of scalability and stability issues. It is suggested that the standard mechanisms available with J2EE and JSF should be used to enact the storage of temporary values.


  3. Keep page level backing beans in “request scope”, if possible

    Ineffective application designs lead to high cost of memory utilization and potential memory leak. The page level backing beans which are maintained in the "session scope" has high memory usage, and since backing bean is maintained in “session scope”, it stays in all the screens at all the time until the user logout the application.


  4. Usage of parameter com.ibm.faces.portlet.UPDATE_LOCALE in web.xml

    In WebSphere Portal Server there is a button/link to select the language/locale to use. When this button is clicked, all the portlets are re-rendered. Since the portal has already rendered once, there exists a view state for the portlet page to render, so it will be "restored". If the bridge does not reset the locale, then the page would just re-render using the old locale. User can set the value of this parameter as true or false for updating the locale while restoring the view.


  5. In case of portlets that extend FacesPortlet and need to implement custom navigation between pages (that is, anything that goes beyond the standard JSF navigation provided by a Navigation Handler), it’s recommended to implement getView() method and return a valid View ID.


  6. The default number of views that is stored in session is 15 when using State saving method of Server by default is up to 15. Once that number of views is reached then the oldest view is removed once a new view is stored. Depending on the application, and business needs, usually that high number is not required. This also tends to consume a lot of memory for each session especially if the pages tend to be complex. Typically users configure the following context parameters in the web.xml to 2 or 3 and adjust the number according to their testing results.

    Note: Keep in mind the need for the views while navigating back to previous pages and the Back button of the browser.

    com.ibm.faces.ENHANCED_SERVER_STATE_SAVING_SESSION_STORED_VIEWS from 15 to 2 |
    com.sun.faces.NUMBER_OF_VIEWS_IN_SESSION from 15 to 2 com.sun.faces.NUMBER_OF_VIEWS_IN_LOGICAL_VIEW_IN_SESSION from 15 to 2


  7. Prior to going to production, remove the following parameter from the facesconfig.xml since it is only used for development and adds a performance overhead that can be removed while running in production:

    <state-manager>com.ibm.faces.application.DevelopmentStateManager</state-manager>


  8. If your application is not leveraging the Ajax tooling from the JWL components, remove the following two entries to remove the performance overhead these settings will have:

    <faces-context-factory>com.ibm.faces.context.AjaxFacesContextFactory</faces-context-factory>

    <render-kit-factory>com.ibm.faces.renderkit.AjaxRenderKitFactory</render-kit-factory>


Appendix:

Recent fixes to IBM JSF Portlet Bridge (jsf-portletbridge.jar)

S.No
Complain
Fixed-in
1 JSF graphic image tag was working on WP V6.0 but broken on WP V6.1 with WebSphere Application Server V7.0

<hx:graphicImageEx styleClass="graphicImageEx"

id="imasgeEx4" value="theme/icons/person.gif"

hspace="5" border="0">

</hx:graphicImageEx>


Rational Application Developer for WebSphere Software v7.5.5.1

2 portletPreferences not working on WP V6.1.x on WebSphere Application Server V7.0
3 For JSR 286 portlets that implement new methods such as serveResource or receiveMessage, one was not able to acquire FacesContext easily . These new methods are not supported by the bridge and to implement these methods it’s required to over-ride getFacesContext and getLifecycle methods. However, bridge provides private access to these modifiers. This has been relaxed to protected.
4 While migrating from WP V5.1 or WP V6.0 projects created using old Rational Application Developer for WebSphere Software V7.0 versions to WP V6.1 the context-param

com.ibm.faces.portlet.USE_RENDER_PARAMETERS in web.xml will be set to "false". This is to enable the bridge to use session instead of Render Parameters.

This has now been automated, and Rational Application Developer for WebSphere Software migration tool would set it during project migration.

5 A new parameter com.ibm.faces.portlet.UPDATE_LOCALE in web.xml has been added in Rational Application Developer for WebSphere Software 7.5.3.

User can set this parameter as true or false for updating the locale while restoring the view as explained in section ‘Usage of parameter com… above’.


Rational Application Developer for WebSphere Software v7.5.3
6 Faces context and external context were not released because of which memory consumption was high. Context should be released after Action and Render phase. Rational Application Developer for WebSphere Software v7.5.3

Document information

More support for: Rational Application Developer for WebSphere Software
Portal / Portlet Development

Software version: 7.0.0.1, 7.0.0.2, 7.0.0.3, 7.0.0.4, 7.0.0.5, 7.0.0.6, 7.0.0.7, 7.0.0.8, 7.0.0.9, 7.0.0.10, 7.5, 7.5.1, 7.5.2, 7.5.3, 7.5.4, 7.5.5, 7.5.5.1

Operating system(s): Linux, Windows

Software edition: All Editions

Reference #: 1424426

Modified date: 27 September 2010