Pages

Friday, August 30, 2013

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.

Wednesday, August 28, 2013

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.

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.

Tuesday, August 06, 2013

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.

Saturday, August 03, 2013

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!

Friday, August 02, 2013

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.