JSF 2.x Tip of the Day: FacesMessage Severity Differences Between Mojarra and MyFaces

Introduction

We encountered an inconsistency between MyFaces and Mojarra that I was surprised was not addressed a long time ago. The issue has to do with the ordinal values assigned to the FacesMessage.Severity. Mojarra uses a zero(0) based level of Severity and MyFaces uses a one(1) based Severity level. As a result, we were trying to use a <rich:notifyMessages/> component with, as you can expect, some unexpected results.

One of the items I always preach is to code to the API. If you code to the API, then you can switch out the implementations should the need occur. This is a best practice, but can be undermined by little subtleties like this. Please don't get me wrong, both Mojarra and MyFaces are great implementations. It is these fine differences that should be consistent that we need to work on to make sure that we are consistent, and that the dream is real; switching implementations will not be painful.

RichFaces is a good framework, and folks like Brian Leathem take personal pride in making it a good implementation to run on top of either Mojarra, or MyFaces. I was really surprised by my discovery of an issue with <rich:notifyMessages/> since the <rich:messages/> works correctly. The problem is focused on the ordinal value I mentioned. I opened a JIRA issue with both MyFaces and RichFaces around the ordinal issue. Please see the references below for details.

However, I needed a solution not just report an issue. So I came up with a 10¢ solution based on some work I did at home last night, and a great suggestion by one of my team. I wanted to publish an article, a complaint, and a solution that others may need. These work arounds tend to become more common when doing cross-platform development, and sharing is paramount.

Problem

The RichFaces <rich:notifyMessages/> does not work consistently across JSF implementations based on Severity ordinal values.

Solution

Implement a method that checks the FacesMessage.Severity ordinal values, and change icons and CSS to correct the differences between implementations. We can accomplish this using CSS, and Expression Language (EL) combined with a page backing bean. In this case, I use a simple page backing bean, but it could be converted to a custom EL function.

The code for this example can be found here: myfaces-rf-example

default.css

---

iconURL()

---

This simple solution allows us to check to see if the implementation starts at 0, or 1 and changes the icons and CSS.

References

• MYFACES-3768 FacesMessage Severity ordinal values are not consistent with Mojarra RI
• RF-13161 rich:notifyMessages CSS incorrect on MyFaces 2.x
• myfaces-rf-example

JSF 2.x Tip of the Day: Guice ELResolver using SLF4J Logging

Introduction

I was recently tasked with looking at some mechanisms to control logging in our JSF applications. This included a number of proof of concept ideas to see which Dependency Injection (DI) mechanisms we could use. We are currently using CDI (Weld), and OpenWebbeans in our applications. I had previously used Guice for doing DI in some other applications especially in Java SE which I found it very easy to use.

As I looked around, I found that I could not find a good example of how to use Guice with JSF 2.x. There were a number of articles from over the years for using Guice with JSF 1.2 primarily, but nothing that used some of the great enhancements to JSF 2. I also found very little on how to implement FacesWrapper to wrap ApplicationFactory, Application, and ELResolver. The exception being ELResolver code that you can find in OmniFaces.

Implementation

The implementation uses a number of techniques to inject our custom ELResolver. First we will use a FacesWrapper to wrap the ApplicationFactory. Our implementation will return a custom ApplicationWrapper implementation, that will return a custom FacesWrapper for our ELResolver. This arrangement may seem complex, but separates the concerns to allow us to refactor them as necessary.

The code for this project can be found here: jsf-guice-logger-integration

GuiceServletContextListenerImpl.java

FacesApplicationFactoryWrapper.java

FacesApplicationWrapper.java

GuiceELResolverWrapper.java

faces-config.xml

There are additional classes that do the logging that can be found in the project. The primary interest here is how to get an ELResolver implementation that will resolve our Guice injections. I hope this demonstration of JSF 2.x wrappers can show you how easy it is to implement custom wrappers including a custom ELResolver.

References

• Integrating Guice and JSF - This is a JSF 1.2 example.
• JSF ELResolver Example
• Custom Injections
• SLF4J Logger Injection with Guice
• Logging with SLF4J and Guice
• DZone - Guice EL Resolver For JSF - This is a JSF 1.2 implementation

JSF 2.x Tip of the Day: jsf.js AJAX onEvent() and onError() Examples

I was looking for some information on what I could do with the jsf.js AJAX scripts in JSF. Specifically, I was wondering if I could do some event handling, and how it should be accomplished. I was surprised that there really was not a complete example that I could find. I did find some blog posts from Jim Driscoll and some comments on stackoverflow by +Bauke Scholtz which show a partial solution, but nothing complete.

I decided to combine the good parts of Jim's blog post with some of the goodies from +Bauke Scholtz to create a complete example. In this example, I use a solution from Jim to demonstrate the events that are returned from the onEvent() and onError() listeners.  Along with a common request... A spinner for AJAX requests.

Once you download, and run the code. You will see a spinner while the AJAX request is processing. In my case, I use a Thread.sleep(2000); to cause the spinner to display for a little while.

The code for project can be found here: jsf-ajax-demo

index.xhtml

---

IndexBean.java

---

References

This is based on the primarily on the work published by Jim Driscoll and Bauke Scholz. This is just a more complete example  of what they mentioned in their articles.

• JSR-314 JavaServer™ Faces Specification 2.1 - Chapter 14 - Javascript API
• jsf.js JSDoc
• JSF 2: Ajax Events and Errors
• JSF handleAjax()
• jQuery “Please Wait, Loading…” animation?
• AJAX Loaders (ajaxload.info)
• JSF 2: Ajax Events and Errors

JSF/CDI Tip of the Day: @PostConstruct Lifecycle Interceptor

SR-71

I was trying to come up with a way to inject a logger into a JSF managed bean that can be done prior to @Postconstruct. I was unsuccessful with this technique, but it was not a total loss. The examples I found on interceptors for life-cycle interception were "empty". They generally mention you can do it, but they did not show any real useful examples.

I hope to change that with this example. The example I demonstrate could be easily done with constructor injection, but in the case of a no-args constructor this may be your only opportunity to inject objects during @PostConstruct. I am going to suggest that if you want to make this functionality more general, you should use an interface and call the interface methods.

The InvocationContext will return Class<? extends T> using context.getTarget(). We can use this concept to control our injection to the object. In my case, I use setter injection on the object. Pretty cool!

The code for this example can be downloaded from here: cdi-lifecycle-interceptor-example

There are a couple of classes needed to set up our @Interceptor. The first is an interface we will call Loggable and the second is an @InterceptorBinding.

Loggable.java

---

This is a simple interface which we will apply to the interceptor, and to the target class that we want to intercept.

Interceptable.java

---

The next class we need is our @Interceptor. This code contains all of the magic we need for the target class which we are intercepting.

PostConstructInterceptor.java

---

As you can see we are making changes to the class after it is constructed, and before the @PostConstruct method is executed, i.e., context.proceed().

Finally, we need to have our class that we are intercepting. In this case, it is a simple @Named and @RequestScoped CDI bean.

IndexBean.java

---

The magic is complete, but I would recommend downloading the Maven based project to see the whole example here: cdi-lifecycle-interceptor-example

Our final output is shown here.

UUID Please?

JSF Tip of the Day: How do I reset input fields after a validation failure?

I was asked earlier today how to reset fields in a JSF application, if the validation fails. In his case, he had a Richfaces table which had values that were selectable. Once the value was selected, a pop-up box would appear in which you could change values. If the user input an incorrect value, the validation would fail and the box would remain. However, if he closed the box, or hit cancel... well it would retain the error values. If he selected another row from the table, it would contain the previous values.

This is a common issue, but he could not find a quick solution so I wrote one.

This function fetches the parent component which in his case was a form containing <h:inputText/> components, and then clears them. You may need to add some more code to do it recursively if the components are nested.