JSF, Portal 6 and pain.

My current project is using JSF with WebSphere Portal 6.0 and RAD 7.0.  I can’t recall being so frustrated while coding.  Coding is usually my favorite part, not this time.

One of the gems so far is outlined in this technote on IBM’s site:  Cannot pass values between Action and Render phase in portlets using JSF in Portal 6.0.

Request scope managed beans do not persist during render phase on JSF JSR-168 Portlets in Rational® Application Developer (RAD) version 7.x
Symptom
a) After submitting changed control - such as the h:inputText element - to a JSF action, an output field does not show the changed value.
b) Constructors of custom JSF components are called twice.

c) A pager which shows for example the third page jumps back to the first page
Cause
The JSF specifications do not explicitly address the interaction between the portal action and render phases. In the previous JSF portlet bridge from RAD 6 (this was deprecated but it is still usable) heavy use was made of the session for getting information from the portlet action phase to the render phase. This is generally not advisable.
To workaround this problem and also to address another issue that existed which could arise during “refresh” scenarios (an action event in a first JSF portlet causing new content displayed for this first portlet. A subsequent action in a second portlet will cause the first portlet to “refresh”) the new JSF portlet bridge from RAD v7.x uses portlet render parameters to pass information between phases.
An unintended side affect is that in some situations the request scope managed bean will not work in v7.x.

Resolving the problem
The new JSF portlet bridge will create render parameters for the following objects:

    •Objects of type java.lang.String

    •Objects that implement java.io.Serializable. You might need to modify certain fields to use the keyword transient so that they get not serialized. This is necessary if you do not have or access to the source code or the field is accessed via a method which creates the instance on demand.

    •View state. A JSF view is not serializable by default but the JSF API provides a mechanism to be able to get state that can be serialized.

So, to make request scope beans usable for a portlet render phase (and a refresh) they must be made Serializable.

So IBM’s implementation requires everything to be serializable.  Oh joy.

The last several projects I’ve worked on have used Spring MVC and I really wish I was using it now…..

February 11th, 2009 in Portal