Multiple Beans are Eligible for Injection


In some cases you may want to inject a controller (another backing bean) into another controller. In Eclipse it will show a warning: Multiple beans are eligible for injection to the injection point. This may prevent your server from starting.

The solution is to provide CDI with the name of the property to inject. The @Named annotation is shown below:

Now CDI will know the proper controller to inject.

Using a comparator to sort 2 separate instances


Consider you have 2 separate classes; “dog” and “cat”. Both of these classes share a common interest in that they are animals. Each of these animals have a date of birth. In this example I will demonstrate how to merge 2 object arrays of both types (“dog” and “cat”) and sort them by their common property; date of birth.

Where might I need this?

In the case of needing both cats and dogs on the same dataTable in JSF this would provide a merged object array to iterate through.

The Code

Creating the abstract class “animal” to be extended by both the dog and cat classes. This abstract class defines what both a cat and dog have in common; a name.

Both the cat and dog classes are very similar. For the purpose of this tutorial they both only have a date of birth.

The dog class is identical to the cat class.

The Solution

To sort both cats and dogs by date of birth first begin by creating a list of each type then adding a few objects to each. The code below adds 2 animals to each type. Then all objects are added to a list of object array. Using collection.sort comparator it checks which type of object is being passed. It then casts that object to its instance type and gets the date of birth. The final statement in the method is the compareTo function which compares the date of birth for each type. Using this approach you can see that you could easily add additional object array types and sort them all by a common date.

The following code is available on Github.

JSF session based queued flash messages


This article is intended to expand on the first article “JSF Bootstrap Style Validation” by adding sessions to store messages between views.

Other examples use getFlash() or phase listeners to intercept the messages:

This solution uses session map instead to store the messages in between views. Using this class will allow for messages to sit in the queue until they are rendered out, this could happen 1,2,3…. pages later.

These two methods when added to the existing getMessages and queueMessage methods add session based messaging. Saving messages is handled by storing all queued messages into the existing faces session map. Then when we restore all messages it grabs the messages from the session map and adds them back to the current facesContext for rendering.

Looking for the rest of the code? View the first article “JSF Bootstrap Style Validation” or checkout the code on found on Github.

Bootstrap-datetimepicker with jsf change events


A datepicker is a great way to avoid having to require multiple inputs on a web application. This example shows you how to use the bootstrap-datepicker and tie it together with JSF.

We begin by creating our inputText field

Now to explain some of the attributes:

The p:data-date-format and p:placeholder are both pass through attributes that become html5 tags. I do this by defining my xmlns at the top of the page like so:

To get our date picker to work we must include the libraries. I choose to use a CDN for my libraries to reduce the configuration on my end. Initialize the datetimepicker to the startDate ID referenced from above. Then create an on change event for the datepicker. This is because the bootstrap-datepicker sits on top of the inputText field and when its value is changed, JSF does not get alerted of this. So inside the change event retrieve the document element of the inputText field then send a onchange event to all other scripts listening to that field. This will trigger the JSF on change event bound by the f:ajax.

Tomcat 7 JDBC Connection Pooler Configuration


Tomcat 7.0.40 has a issue running the standard connection pooler. Following the Apache tutorial can lead to a error

The solution is to add a different factory reference to your resource definition.



This should solve the issue with Tomcat selecting the inappropriate factory for connection pooling.