In many projects I found the situation that the client didn’t want to pull in another framework just for that little feature. Also for distributing responsibilities, I usually have multiple managed beans per view. So another “artificial” page bean is required just for controlling the others. So I came up with a fairly simple solution that allows to directly invoke those life-cycle callbacks on any managed bean used on a single page.

The <f:phaseListener> tag allows to bind a JSF PhaseListener. You can even bind multiple phase listeners (one for each managed bean; you get the idea).

<f:phaseListener binding="#{bean1.viewControllerPhaseListener}" />
<f:phaseListener binding="#{bean2.viewControllerPhaseListener}" />

So each of the beans would provide a reference to a phase listener that would take care to perform the proper processing for the bean itself. Every bean then would use a set of annotations (like @PreRenderView, @PostRestoreView, @PreInvokeApplication, etc.) to mark those methods that should be called during a specific phase.

public class EntityListController<T> {
	private volatile ViewControllerPhaseListener viewControllerPhaseListener;

	public ViewControllerPhaseListener getViewControllerPhaseListener() {
		if (viewControllerPhaseListener == null) {
			viewControllerPhaseListener = new ViewControllerPhaseListener(this);
		}
		return viewControllerPhaseListener;
	}

	@PreRenderView
	public void updateModel() {
		...
	}

	...

The code above is partially showing a base class from which many of my managed bean are subclassed. Key is the ViewControllerPhaseListener which hides all of the details of doing the reflection job for finding (and then caching) the annotated methods to invoke during a specific phase. For brevity I’m showing only the key elements of this class.

public class ViewControllerPhaseListener implements PhaseListener {
	private final Object target;

	public ViewControllerPhaseListener(Object target) {
		super();
		this.target = target;
	}

	private final Class<Annotation>[] LIFECYCLE_ANNOTATIONS = new Class[] { PreRenderView.class, PostRestoreView.class,
		PreInvokeApplication.class };

	private final static Map<Class<?>, Map<Class<? extends Annotation>, Set<Method>>> controllerClasses = new ConcurrentHashMap<Class<?>, Map<Class<? extends Annotation>, Set<Method>>>();

	static Map<Class<?>, Map<Class<? extends Annotation>, Set<Method>>> getControllerClasses() {
		return controllerClasses;
	}

	@Override
	public void beforePhase(PhaseEvent event) {
		if (PhaseId.RENDER_RESPONSE.equals(event.getPhaseId())) {
			invokeAnnotatedMethod(PreRenderView.class, target);
		} else if (PhaseId.INVOKE_APPLICATION.equals(event.getPhaseId())) {
			invokeAnnotatedMethod(PreInvokeApplication.class, target);
		}
	}

	@Override
	public void afterPhase(PhaseEvent event) {
		if (PhaseId.RESTORE_VIEW.equals(event.getPhaseId())) {
			invokeAnnotatedMethod(PostRestoreView.class, target);
		}
	}

	@Override
	public PhaseId getPhaseId() {
		return PhaseId.ANY_PHASE;
	}

	void invokeAnnotatedMethod(Class<? extends Annotation> annotation, Object targetObject) {
		if (!controllerClasses.containsKey(targetObject.getClass())) {
			registerController(targetObject.getClass());
		}
		for (Method method : controllerClasses.get(targetObject.getClass()).get(annotation)) {
			try {
				method.invoke(targetObject);
			} catch (Exception e) {
				LOGGER.error("Error invoking @{} annotated method {} on {}", new Object[] { annotation.getSimpleName(),
						method, targetObject });
				throw new RuntimeException(e);
			}
		}
	}

	public void registerController(Class<?> controllerClass) {
		// do the reflection work
	}
}

In a few projects this has proven to be quite versatile. Currently I have a couple of interesting phase listener components, from the simple DebugPhaseListener to the OpenTransactionInViewPhaseListener. I can just throw them into any view as they are required.

<h:outputText value="#{day.date}">
	<f:convertDateTime type="date" pattern="dd.MM.yyyy" timeZone="#{viewController.timeZoneId}"/>
</h:outputText>

The latter approach allows to have a single point of detecting a users timezone preference (unfortunately the timezone is not included in the HTTP header) but requires to have the timezone attribute implemented in multiple places.

So far so good. Many solutions propose using the timezone offset based timezone identifier which turns out to be bad. It doesn’t allow the JDK date formatters to properly apply the daylight settings. So better use “Europe/Vienna” instead of “GMT+1″. It even looks like there were some subtle changes with turning from JDK 1.5 to JDK 1.6 regarding this.

public boolean isSevereMessage() {
	Severity severity = FacesContext.getCurrentInstance().getMaximumSeverity();
	return severity == null ? false : severity.compareTo(FacesMessage.SEVERITY_INFO) > 0;
}

Seems that could go into the FacesContext implementation, right? In order to get there you need a FacesContextFactory that instantiates your FacesContext implementation.

The FacesContextFactory is setup by a FactoryFinder which supports quite a few strategies for picking up the factory.

public class BlueprintFacesContextFactory extends FacesContextFactory {
	private final FacesContextFactory factory;
	public BlueprintFacesContextFactory(FacesContextFactory factory) {
		super();
		this.factory = factory;
	}
	@Override
	public FacesContext getFacesContext(Object context, Object request, Object response, Lifecycle lifecycle)
			throws FacesException {
		return new BlueprintFacesContext(factory.getFacesContext(context, request, response, lifecycle));
	}
}

By implementing a constructor that takes a FacesContextFactory as argument we can easily get hold of the factory provided by the JSF implementation and delegate.

For our FacesContext implementation the deal is to wrap the existing FacesContext with your own implementation. Therefore it also implements a constructor taking a Facescontext as argument.

public class BlueprintFacesContext extends FacesContext {
	private final FacesContext context;
	public BlueprintFacesContext(FacesContext context) {
		super();
		this.context = context;
		setCurrentInstance(this);
	}

	/**
	 * Test if a request processing resulted in a severe message. A message is
	 * considered severe if it is more severe than INFO.
	 *
	 * @return true if
	 *         <code>maximumSeverity.compareTo(FacesMessage.SEVERITY_INFO) > 0</code>
	 */
	public boolean isSevereMessage() {
		Severity severity = getMaximumSeverity();
		return severity == null ? false : severity.compareTo(FacesMessage.SEVERITY_INFO) > 0;
	}
	@Override
	public ELContext getELContext() {
		ELContext elContext = context.getELContext();
		elContext.putContext(FacesContext.class, this);
		return elContext;
	}
	//other methods stripped for brevity, they only delegate to context!

With JSF2 a FacesContextWrapper is provided so only those methods need to overridden that are required to add the desired behaviour.
Here I needed to override getELContext in order to make the custom FacesContext available in EL expressions.

<p:dialog widgetVar="widget" id="dialog"
	visible="#{not empty facesContext.maximumSeverity}">
	<f:facet name="header">
		<h:outputText value="Form" />
	</f:facet>
	<h:form>
		<h:panelGrid columns="3">
			<h:outputLabel for="input" value="Input" />
			<h:inputText id="input" label="Input" required="true" value="VALUE" />
			<h:message for="input" />
		</h:panelGrid>

		<h:panelGroup>
			<!-- update the form for the case we get validation errors -->
			<p:commandButton value="Update" update="dialog"/>
		</h:panelGroup>
	</h:form>
</p:dialog>

Today I want to put this idea a little bit further and add another convenicent facelets tag that will allow to assign a style class to any UI element based on validation results. In order to create an appealing form that clearly indicates the position where validation fails very often you see that input elements change their visual appearance based on the validation state. For example any invalid input element is shown with red background. With no component you end up with tedious (or complex) EL expressions that are assigned to the styleClass attribute.

To make that concept reusable and simple to apply I show how to create a facelets tag setStyleClassIfMessages that evaluates the faces messages available for a specific component, looks for the message with highest severity and uses the severity to apply a CSS style class to any component.

The tag implementation is quite straightforward, I have stripped some obvious details from the code.

public class SetStyleClassIfMessagesTagHandler extends MessagesTagHandler {

	protected final TagAttribute[] classAttributes = new TagAttribute[5];

	public SetStyleClassIfMessagesTagHandler(TagConfig config) {
		super(config);
		classAttributes[0] = getAttribute("passedClass");
		classAttributes[FacesMessage.SEVERITY_INFO.getOrdinal() + 1] = getAttribute("infoClass");
		classAttributes[FacesMessage.SEVERITY_WARN.getOrdinal() + 1] = getAttribute("warnClass");
		classAttributes[FacesMessage.SEVERITY_ERROR.getOrdinal() + 1] = getAttribute("errorClass");
		classAttributes[FacesMessage.SEVERITY_FATAL.getOrdinal() + 1] = getAttribute("fatalClass");
	}

	public void apply(FaceletContext ctx, UIComponent parent) throws IOException, FacesException, FaceletException,
			ELException {
		if (forAttribute != null) {
			UIComponent forComponent = getForComponent(ctx.getFacesContext(), forAttribute.getValue(ctx), parent);
			if (forComponent != null) {
				setMaximumSeverityStyleClass(ctx, forComponent);
			} else {
				LOGGER.warn("No component {} found.", forAttribute.getValue(ctx));
			}
		} else if (parent != null) {
			setMaximumSeverityStyleClass(ctx, parent);
		}
	}

	private void setMaximumSeverityStyleClass(FaceletContext ctx, UIComponent forComponent) {
		FacesMessage message = findMostSevereMessage(ctx.getFacesContext(), forComponent);
		if (PropertyUtils.isWriteable(forComponent, STYLE_CLASS_PROPERTY_NAME)) {
			TagAttribute messageStyleClass = message == null ? classAttributes[0] : classAttributes[message
					.getSeverity().getOrdinal() + 1];
			try {
				StringBuilder newStyleClass = new StringBuilder(messageStyleClass == null ? "" : messageStyleClass
						.getValue(ctx));
				// read style and remove style class from previous post-back,
				// then set new style class
				String oldStyleClass = (String) PropertyUtils
						.getSimpleProperty(forComponent, STYLE_CLASS_PROPERTY_NAME);

				Set<String> classNames = new HashSet<String>();
				for (TagAttribute classAttribute : classAttributes) {
					if (classAttribute != null) {
						classNames.add(classAttribute.getValue());
					}
				}
				StringTokenizer tokenizer = new StringTokenizer(oldStyleClass == null ? "" : oldStyleClass, " ");
				while (tokenizer.hasMoreElements()) {
					String styleClass = tokenizer.nextToken();
					if (classNames.contains(styleClass)) {
						continue;
					}
					newStyleClass.append(' ').append(styleClass);
				}
				PropertyUtils.setSimpleProperty(forComponent, STYLE_CLASS_PROPERTY_NAME, newStyleClass.toString());
			} catch (Exception e) {
				throw new FaceletException(e);
			}
		}
	}
}

JSF components offer a boolean rendered attribute that allows controling the rendering process. For complex decisions that means that a method on a managed bean would calculate the resulting state.

Exactly that was the solution that I was starting with for the problem described above.

public Map<String, Boolean> getHasMessages() {
	HashMap<String, Boolean> flags = new HashMap<String, Boolean>(1);
	Iterator<String> messages = FacesContext.getCurrentInstance().getClientIdsWithMessages();
	while (messages.hasNext()) {
		flags.put(messages.next(), Boolean.TRUE);
	}
	return flags;
}

<h:inputText label="Amount" id="amount" >
	<p:tooltip for="amount" showEvent="focus" hideEvent="blur" rendered="#{mbean.hasMessages['amount']}">
		<h:message for="amount" />
	</p:tooltip>
</h:inputText>

So I had a simple solution working fairly quickly. But let’s face it: It’s a clumsy solution that is hard to reuse and breaks when the id of the ui container around the input is changed.

To improve that, I decided that this requires a component that would be simple to reuse. As I’m using Facelets for the view I updated my knowledge of their support for custom components.

public class IfMessagesTagHandler extends TagHandler {
	private static final Logger LOGGER = LoggerFactory.getLogger(IfMessagesTagHandler.class);
	private static final String FOR_ATTRIBUTE_NAME = "for";
	private final TagAttribute forAttribute;

	public IfMessagesTagHandler(TagConfig config) {
		super(config);
		forAttribute = getAttribute(FOR_ATTRIBUTE_NAME);
	}

	public void apply(FaceletContext ctx, UIComponent parent) throws IOException, FacesException, FaceletException,
			ELException {
		if (forAttribute != null) {
			UIComponent forComponent = getForComponent(ctx.getFacesContext(), forAttribute.getValue(ctx), parent);
			if (forComponent != null) {
				if (ctx.getFacesContext().getMessages(forComponent.getClientId(ctx.getFacesContext())).hasNext()) {
					this.nextHandler.apply(ctx, parent);
				}
			} else {
				LOGGER.warn("No component {} found.", forAttribute.getValue(ctx));
			}
		} else if (parent != null) {
			if (ctx.getFacesContext().getMessages(parent.getClientId(ctx.getFacesContext())).hasNext()) {
				this.nextHandler.apply(ctx, parent);
			}
		}
	}
}

The above implementation accepts the optional attribute for that refers to a component id for which it tests if messages are available. In case the for attribute was not passed the tag would assume that the component to test for messages is the enclosing parent tag.

To register the tag handler a facelets tag library descriptor in META-INF is required.

<?xml version="1.0"?>

<!DOCTYPE facelet-taglib PUBLIC
  "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
  "http://java.sun.com/dtd/facelet-taglib_1_0.dtd">

<facelet-taglib>
	<namespace>http://martinahrer.at/jsf/facelets/blueprint</namespace>
	<tag>
		<tag-name>ifMessages</tag-name>
		<handler-class>at...view.facelets.IfMessagesTagHandler</handler-class>
	</tag>
</facelet-taglib>

A client would use that tag as:

<h:inputText label="Amount" id="amount" value="#{expenseSlipFormController.entity.amount}" required="true">
	<b:ifMessages >
		<p:tooltip for="amount" showEvent="focus" hideEvent="blur" style="myStyle">
			<h:message for="amount" />
		</p:tooltip>
	</b:ifMessages>
</h:inputText>

At the end of the RESTORE_VIEW phase the listener would decode the request URL and extract a managed property reference expression, create an EL expression and get the byte array for the binary document.

	public void afterPhase(PhaseEvent event) {
		String viewId = event.getFacesContext().getViewRoot().getViewId();
		if (viewId.startsWith(PDF_STREAM_VIEW_ID_PREFIX)) {
			String streamExpression = StringUtils.substringAfter(viewId, PDF_STREAM_VIEW_ID_PREFIX);
			ELContext elContext = event.getFacesContext().getELContext();

			byte[] bytes = (byte[]) event.getFacesContext().getApplication().getExpressionFactory()
					.createValueExpression(elContext, "#{" + streamExpression + "}", byte[].class).getValue(elContext);
			if (bytes != null) {
				HttpServletResponse response = (HttpServletResponse) event.getFacesContext().getExternalContext()
						.getResponse();
				response.setContentType("application/pdf");
				response.setContentLength(bytes.length);

				try {
					response.getOutputStream().write(bytes);
				} catch (Exception exception) {
					LOG.error(exception.getMessage());
				}
			}
			event.getFacesContext().responseComplete();
		}
	}

To display the binary document a matching URL needs to be generated. Here the <object> tag is used for displaying a PDF document. The URL part after “/pdf/stream/” is used as a part of a value expression for referencing the actual PDF binary document (here it is managedBeanName.propertyName).

	<object
		data="#{facesContext.externalContext.requestContextPath}/#{facesContext.externalContext.requestServletPath}/pdf/stream/managedBeanName.propertyName"
			type="application/pdf" />

IBM still hasn’t released a JavaEE 5 compliant product, so the 6.1 version is still on J2SE 1.4 with JSP 2.0 and Java Servlet 2.4. Also it has a built-in JSF 1.1.

The application to be migrated luckly is using facelets as its view technology otherwise I would have been screwed anyway. JSF 1.2 itself doesn’t rely on the servlet spec 2.4 so a good chance to get it done.

To run JSF 1.2 the following is required:

1. Make sure that you WebSphere installation is at least running with fixpack 13!
2. Create a shared library containing JSF RI 1.2 jars (jsf-api.jar, jsf-impl.jar, el-api-1.0.jar, el-impl-1.0.jar)
3. Create a classloader with application classes loaded first and bind it to the shared library above
4. Set the classloading policy as application classes loaded first and assign the classloader

If you are using other popular JSF component libraries, things might get a bit more handy (you can avoid including tomahawk just for fully controlling the input ids!).

With Myfaces Trinidad (Oracle ADF Faces) it is pretty easy, ids are accepted as they are:

With JBoss Rich-Faces use the a4j:form tag: