PrettyFaces offers a very simple and flexible way to create bookmark-able RESTful URLs in JSF applications. This short article will show you how easy it is to use PrettyFaces for serving other dynamic content like images or PDF files. Many applications are required to generate some kind of “dynamic” content for the user. A typical example are product images in a web shop. These are mostly not deployed with the application archive but rather stored in an external directory or a database. Another example are PDF reports that are generated on demand when a user requests them.

Do you have an existing Maven-based Java EE application that you’d like to clean up a bit in the browser? Do your URLs look too much like this: http://example.com/app/sillyServletName/someStuff?sillyParam=22&sillyOtherParam=profile And not enough like this? http://example.com/app/profile/22 Are you building a new application, and don’t want to sacrifice anything when it comes to usability or SEO capabilities? Well, URL-rewriting is your answer, and it’s easy to get started, even easier using JBoss Forge.

I was recently asked the question, “Is it possible to create a modular JSF application, where JAR-files act as plug-ins and allow xhtml views, images, css, navigation rules, and managed beans to be added as modules to the application?” The answer to this question is, “of course,” but there is no pre-set way of accomplishing such a task, so you’ll have to be a little creative. I’ve come up with a conceptual architecture that “would work,” if properly implemented, but keep in mind that this is just something I threw together in a few minutes of thinking about the problem.

PrettyFaces is an OpenSource Filter-based Servlets extension with enhanced support for JavaServer Faces – JSF 1.1, 1.2 and 2.0 – enabling creation of bookmark-able, pretty URLs. PrettyFaces solves the “RESTful URL” problem elegantly, including features such as: page-load actions, seamless integration with faces navigation, dynamic view-id assignment, managed parameter parsing, and configuration-free compatibility with other web frameworks.

A recent thread came up on the JSF 2 forums: “Why can’t I use @Inject in a PhaseListener? This CDI stuff is so confusing.” FIrst, before I start explaining: this is possible, but there’s a little background you should probably know. The answer to the question “why can’t I use CDI in JSF PhaseListeners?” is: because JSF 2 was completed just a few short months before JSR-299 and the rest of the Java EE 6 platform specifications were finalized. In my opinion – because of the current state-of-affairs in the JCP – it was just not a safe bet to promise integration with other technologies that might not have been finalized in time. Fortunately, however, JSF goes to extra lengths in providing extension points – solving this with an extension was not too difficult.

So Java EE 6 is out, and you’ve decided to give it a go. You’re trying to port an existing application over to the new stack (or are trying to create a new one for the first time,) but exceptions are bursting through the seams and you just can’t seem to get things to work. If you’re familiar with Spring and Hibernate (with all the joy that is OpenSessionInView or OpenSessionInConversation,) more than likely the problems you’re having are related to the Java Persistence API (JPA), combined with Enterprise Java Beans (EJB). Contexts and Dependency Injection (CDI) should be a familiar face if coming from Spring, but things are subtly different in the world of Java EE.

» Get PrettyFaces!

Features & Enhancements:

• Introducing URL mapping configuration with annotations (tutorial + docs)
• Added path and query-parameter validation wth managed bean methods (#50 + r353)
• Added support for JSF2 redirects using ExternalContext (r305)
• Added support for arrays as query parameters (r278)

Regression impact:

• The URL query string is now included in rewrite-rules; this allows for finer control of the rewriting engine (Any prior rewrite rules should be revised and re-tested)
• PrettyContext.getCurrentURL() has been replaced with PrettyContext.getRequestURL() and PrettyContext.getRequestQueryString()

Bugfixes:

• Resolved Mojarra warning “Request path ‘/faces/url.xhtml’ begins with one or more occurrences of the FacesServlet prefix path mapping ‘/faces’.” when using path mapping (#43 + r379)
• Resolved Deployment warning on Geronimo (#58 + r364)
• URL Path Expressions now match correctly when more than one expression is used between path segments (r362)
• Resolved ClassNotFoundException with JSF 1.2 on JBoss6 (#54 + r360)
• Resolved failed deployment due to ClassNotFoundException on Geronimo (#59 + r369)

“The problem is not the system, its the way someone can get in. To be honest, most tutorials, how-tos, and documentation sucks, because they ALL are written like the reader already knows the trick. No doc about [Technology] is written for newbies.”

The PrettyFaces team is currently working on an alternative way to configure URL mappings. PrettyFaces will soon allow to use annotations instead of the classic XML configuration file to declare mappings. We encourage everyone interested in PrettyFaces to take a look at this new way of configuration and share his or her opinion with us.