March 15, 2015

Top tips and links for JSF developers

This is my JSF link list which has proven useful in 5+ years working in that technology. We’ll go from decision making through tool usage to troubleshooting.

Decide: JSF or not?

Even back in the day when JSF 1.0 came out, competing web frameworks have already existed; in the 201* decade, with the rise of client-side JavaScript-based frameworks, a new fundamental choice has been introduced: Whether you want to go with a server-side, or a client-side framework.

Don’t take a rash decision here! It will ultimately decide whether your project will succeed or not. You do not want to find yourself stuck with a tech stack which doesn’t fit your needs anymore halfway through the project. Thus don’t just say: “We do JSF, because everyone does / because we’ve always done it”. Take your time for a thorough assessment.

There are far too many web frameworks, and far too many aspects to consider that I could give you any sensible advice in this short section. I can however give you some food for thought:
Other forces which may make you consider a JSF-based solution include:
  • Additional architectural / security challenges may arise from expose your business logic (middle tier / backend) through a public API to the client.
  • Performance / security considerations when the client UI is built in the web browser when compared with a server-side solution which sends the finished plain HTML site to the client.
  • Maturity of the Java ecosystem (c.f. the technology section below) which may not yet be reached by “up and coming” JavaScript-based solutions.
  • “Isomorphic” use of Java to write both UI controller and service interface code.
  • Existing Java knowledge in your team.
If you do consider choosing any server-side framework, or JSF, specifically, one very general “rule of thumb” I would give from my experience is that for “classical”, form-based applications, JSF holds good. This typically applies to scenarios where you port legacy systems such as former Swing / Excel macro / COBOL / [insert horrible technology here] applications to the web. If, however, a rich, dynamic, responsive, real-time desktop-like behavior of your application is key, I would strongly advice you to check a client-side alternative. I will probably elaborate more deeply on my JSF experience in a future blog post...

Learn: Best resources

As JSF by now is a very mature technology, there are tons of useful resources out there. Two of the best blogs out there are:
  • BalusC: StackOverflow legend and JSF mastermind, the creator of OmniFaces. Provides in-depth tutorials and battle-proven advice.
  • mkyong: Another very experienced JSF guru. His blog provides many very clear, easy-to-follow tutorials for common JSF tasks.
The following list is IMHO a must-read for any JSF development team member. Any JSF developer must be highly familiar with these topics and design patterns:
Also, there is a very elaborate JSF link list on (a knowledge / link sharing platform actually created by BalusC, and programmed in JSF itself).

Note that however, reading though a link list doesn’t substitute reading introductory books, or attending training classes.
Moreover, it is vitally important that you and your team agree on clear standards on how to use these and other basic JSF features (plus features of accompanying technologies). One of the challenges in JSF development is that there are various ways of achieving a given goal, and some of them might violate clean JSF application design. Stick to what eminent experts say, and later adapt, if sensible.

Install: Tools you want to use

First of all, you want to use NetBeans IDE in your project, unless you already have Eclipse IDE expert knowledge in your team or an IntelliJ license at hand. This is what NetBeans offers:
  • It’s very fast and very stable
  • Everything Java EE comes out-of-the-box and preconfigured
  • Preconfigured HotDeployment with Maven on e.g. GlassFish server
  • Many useful features are preconfigured, such as XHTML / EL auto-complete, CRUD controller / view code generation, integrated DB viewer, CSS preprocessors, and more…
Then, you also want to use JRebel for instant re-deploys within milliseconds, without session invalidation. To cite Joel Spolsky: “Top notch development teams don't torture their programmers.” (source)

You’ll also want to make sure that your JVM / server environment is exactly the same from development till production. This will save you from having to analyze your program’s bytecode if you run into some JVM implementation deviations. The traditional approach here is to manually make sure to have the same software installed on every machine, but nowadays there are more modern solutions such as Docker / Vagrant virtualization.

More than often, problems will show up at the client (web browser) level first, so it’s clear that you want to have web development extensions installed in your browser. For Firefox, I use and recommend Firebug plus the Web Developer toolbar.

Addressing software development as a whole, you also typically want to use good tools to help you sketch and document your UI design and software architecture:
  • For UML modelling, I recommend the free, open source tool UMLet (which I also use throughout my blog posts).
  • For UI mockups, I recommend the free, open source tool Pencil (which I also use throughout my blog posts).
There are of course more sophisticated tools available, but these are in general so complex to use (and typically expensive) that they turn out to be actually counter-productive for about 80% of what you will ever use them for. I would always advice to stick with the most simple tool available, and only upgrade when required.

Set up: Technologies you want to use

There are a couple of very good accompanying technologies and frameworks you want to include in your JSF application stack. Not doing so would potentially violate DRY as it would force you to re-invent the wheel and program a homegrown solution for what is already covered by mature, wide-spread and supported frameworks.
  • First of all, you want to use a UI component framework. There are disputed opinions on those frameworks, but apparently, PrimeFaces offers the most sophisticated UI bling and is the most wide-spread whereas RichFaces seems the most robust choice. Under no circumstances you will want to write UI components on your own if there’s a library for that. Oh, and whatever component library you go for: it is mandatory that you get the full-blown (“call us and we’ll fix it”) support package. Otherwise, you will find yourself fixing other people’s frameworks bugs, which is arguably even more nerve-wracking than programming everything yourself. You will make extensive use of the UI framework’s capabilities, and you will potentially have to cross its limitations!
  • If you’re opting for PrimeFaces, you should also include PrimeFaces extensions which provides additional UI components as well as some ease of development util functionality.
  • In any case you want to include the OmniFaces library. Developed by BalusC (see the recommended blogs / links above), this library provides a wide range of features which will greatly increase ease of development, help you reduce boilerplate code and provide default best-practices implementations for many common JSF-related issues. This is a very robust, well-documented library!
  • As an act of shameless self-promotion, I’d also suggest you take a look at CrudFaces. This is a JSF component library / framework I’m currently developing (November 2015) which provides a robust but lean framework to build (optionally RESTful) PrimeFaces-based JSF applications according to well-known best-practices alongside a wide range of generally useful JSF components. It especially offers a great, save starting point for newly-built JSF projects.
  • You want to have a decent “glue” framework to connect your UI with your backend. This will typically be a Java EE CDI implementation such as JBoss Seam Weld (or the Spring framework) + optionally the CDI extension framework Apache DeltaSpike (thanks to Thomas Andraschko for pointing this out!).
  • On a more basic level, you typically want to include a “common Java util” library unless you’re lucky enough to bode on a Java 8+ basis where common functionality like String joining and Date arithmetics can be achieved in an “ease of development” compliant way. Otherwise (as well as for some more sophisticated functionality) you’ll need third party libraries (e.g. Apache Commons, Google Guava, Joda-Time). The rule to maintainability is here: Try using Java 8 functionality first, then try a 3rd party library, and only if nothing meets your requirements, code it yourself. Just add a new library as the need arises.
  • Optional: A “conversation scope” bean scope extension. This comes in handy in a situation where the request scope is too short-living, but view scope is too broad. Such a conversation scope is included in the Java EE CDI specification; if your middle tier tech stack is based on Spring, you’ll be forced to use 3rd party extensions such as Apache MyFaces Orchestra.
  • Optional: PrettyFaces for advanced RESTful, bookmarkable URLs.
  • You want to make sure you can use EL 2.2+ features such as method invocation with parameters. In projects with a decent tech stack, this shouldn’t be a problem nowadays; otherwise, search for help on how to activate EL 2.2 in your environment.
  • Whenever you’re forced to write JavaScript code, you want to use jQuery for convenience. Note that jQuery comes bundled with PrimeFaces already.
  • You want to include a CSS preprocessor such as Saas or LESS. This will greatly reduce boilerplate CSS code and ensure its long-term maintainability.
  • Use Twitter Bootstrap for your overall CSS layout. This will greatly reduce the pain and increase maintainability when it comes to default UI design tasks such as aligning and arranging components.

Code: Common problems and troubleshooting

No matter how well you set up your tool chain, you will almost certainly run into problems when developing more sophisticated webapps. Here’s a collection of solutions for common problems which helped me when in trouble:

Question: For no apparent reason, the server renders crap. What!?

  • Restart the server, and clean / deploy from scratch. Trust me, there’s a good chance that everything will be fine afterwards.
  • Make sure no EL expression is erroneous. Common EL errors include additional whitespaces, e.g. value="#{myController.myProperty }"
  • Make sure the web.xml <context-param> javax.faces.FACELETS_SKIP_COMMENTS is set to true. Otherwise, sections of XHTML you commented out may still render empty placeholders which may tear apart your layout. Also, it may be a security risk to render XHTML comments to the output website. You should always activate this option.

Question: A commandLink/commandButton/ajax backing bean action/listener method not invoked

Answer: This is exhaustively addressed by BalusC in this StackOverflow answer: SO: commandLink/commandButton/ajax backing bean action/listener method not invoked.

I would add to that list that you also check:
  • Every input / action component has a legal “id” attribute.
  • Make sure that process / update attributes (for PrimeFaces commonButton) or execute / render (for JSF commandButton) point to the components you want to include in submit / re-rendering. Note that when using PrimeFaces, commandButton uses ajax per default. In order to disable ajax, you need to add the ajax="false" attribute.
  • If update (PrimeFaces) / render (JSF) is set to "@form", make sure that the component to be re-rendered is actually part of the same form as is the command component.
  • As an addition to “No UIInput value validation/conversion error should have been occurred.”: Note that if you have a multi-step click-path (e.g. open a dialog, then click a button in the dialog), a validation/conversion error could have occurred in the dialog opening already; depending on the ajax configuration, the dialog might just show up, but no subsequent actions are processed until the error is resolved. In that case, make sure validation/conversion errors are processed (i.e. they are shown in <h:message> components) for the entire click-path.
  • Make sure that when invoking a “controller” backing bean, that class is properly registered as a JSF bean (including a scope definition), e.g. it is annotated with javax.inject.@Named and @javax.enterprise.context.SessionScoped (Java EE), or with @org.springframework.stereotype.Controller and @org.springframework.context.annotation.Scope("session") (Spring), or a similar configuration.

When combining on a PrimeFaces p:commandButton update="…" with immediate="true", nothing happens.

Setting immediate="true" is the standard solution to suppress input validation.

Actually, setting immediate="true" skips the entire UPDATE_MODEL phase in the JSF life cycle; thus, an AJAX update is never processed. This is thus not a valid solution for PrimeFaces <p:commandButton> which uses AJAX by default; it only works with explicit ajax="false".

For AJAX <commandButtons>, use process="@none" instead. For AJAX <p:commandButtons>, process (which corresponds to the render attribute on vanilla JSF <f:ajax> tags) determines which values get submitted in the request to the server; it defaults to @form which submits all values in the surrounding form. Hence, if you submit @none, no value gets submitted, and no value can thus get validated.

Because with @none, not even the button press itself will be submitted, you also don’t need any server-side method.

However, in case you also need to reset potential validation errors from previous form submits (i.e. clean previous validation messages), which is typically desired for “reset / clean" button functionality, you need to use a different strategy: Use the dedicated <p:resetInput> tag within the button is question, and make sure the button is executed (process="@this"). Hence, the default solution for an AJAX with “reset / clean" functionality is
<p:commandButton value="clear"
     update="@form" process="@this">
 <p:resetInput target="@form" />
For vanilla JSF component, there is a similar component provided by OmniFaces.

Question: Cannot find component with expression “foo” referenced from “bar”

Answer: Again, see this very helpful thorough answer by BalusC on StackOverflow: SO: Cannot find component with expression “foo” referenced from “bar” - <f:ajax> contains unknown id “foo” cannot locate it in context of component “bar”

Question: Component id has already been found in the view when using conditional rendered attribute

Answer: Yes, BalusC has a solution for that here: SO: JSF Conditional includes, cause Component ID has already been found in the view

Question: dataTable (JSF / PrimeFaces): The class 'foo' does not have the property 'bar'.

Answer: Make sure that the name chosen for the var attribute of dataTable is unique within the page, e.g. it is not used by any other component, a <ui:param> tag, or the like. Otherwise, the var declaration defined in the dataTable would be ignored and the existing value would be taken to populate the table.

For example, this declaration would cause an error:
<ui:param name="item" value="bla"/>
<h:dataTable value="#{myController.models}" var="item">


This blog post provided a very high-level view on JSF application implementation only. It really boiled down to a link list of useful introductory material as well as “quick help” reference. I found this link list really helpful throughout my JSF development carreer, so I thought it’s worth sharing it here.

Programming in JSF is not easy; when it comes to non-trivial tasks, you really need profound knowledge of all your frameworks as well as the underlying technologies. Also note that in this article, we really only concentrated on front-end programming whereas in reality, JSF development typically is deeply interweaved with business tier components (“controllers”, “services”), and even with back-end services such as transactions, persistence, and validation. In any of these abstraction layers, issues may arise which may crawl up all the way to the UI layer, making it hard to locate and thus to solve any given issue.

Please let me know in the comments section whether you found the information in this post useful. If you know other excellent sources for any JSF-related topic I forgot to mention, feel free to share them below. Also please leave me a comment if you’re actually interested in more JSF stuff; then I will probably publish more in-depth JSF-related blog posts in the future.

  • March 20, 2015: Included Java EE CDI and Apache DeltaSpike references.
  • May 3, 2015: Included a reference to my new blog post about Validation, I18N and accessibility.
  • May 17, 2015: Included a reference to my new blog post about RESTful JSF with POST-redirect-GET.
  • May 31, 2015: “Decide” chapter updated.
  • November 15, 2015: “Code: Common problems and troubleshooting” chapter updated; link to CrudFaces added.
  • December 13, 2015: Intro / “Decide” / “Install” / “Setup” chapters updated.


  1. You forgot Apache DeltaSpike! It provides really cool JSF features like multi window handling, type safe view config, enhanced scoped like WindowScoped, ViewAccessScoped, GroupedConversationScoped, a CDI ViewScoped and and and...

    1. Thank you for calling attention to this. I actually intended to keep this article completely focused on the UI layer, that’s why I left out any other Java EE stack recommendations. But I agree that other layers are just as important when designing a JSF application, so I included a reference on Apache DeltaSpike in the setup section. It is indeed a nice addition to any Java EE stack.