Several years ago I wrote a tutorial about using Acegi/Spring Security with JavaServer Faces (JSF) to create a simple authentication / Login page; however, times have changed and Java EE is back in action. I would no longer consider Spring a “requirement” when building a Java EE application. More specifically, if you are using the core Contexts and Dependency Injection (CDI) framework that serves as the backbone for the entire Java EE framework, Spring Security becomes less attractive (because it’s not compatible without using Spring itself, and Spring is a replacement for CDI).

This article will explore how to create a JSF login backed by the standards-compliant CDI framework (that is included with Java EE), and the PicketLink security framework (an open-source project from JBoss). Examples for this article were sourced from the very comprehensive, and quite understandable quick-start application from the PicketLink project itself.

I’m about to show you a pattern that will make your heart sing. I have to thank Brian Leathem for his original idea to use CDI events in the ValueChangeListener, but when combined with a little <f:ajax> magic, there’s almost no limit to what you can do without writing a single line of JavaScript. ValueChangeListeners are also the perfect opportunity to build an Event driven model into your application.

The PrettyFaces team is pleased to announce the release of PrettyFaces 3.3.0. PrettyFaces is an OpenSource 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.

Features & Enhancements:

• Performance improvements when running JSF 2.0 in project stage ‘development’
• Regular expression performance improvements provided by Yann Simon.
• Ambiguous View IDs are now resolved automatically when using pretty:mappingIds in action method navigation, <h:link> and <h:button> component outcomes
• Ambiguous View IDs may now be resolved manually for outbound URL rewrites by adding ‘?com.ocpsoft.mappingId=…’ to URLs before calling HttpServletResponse.encodeURL(…)
• Dynaview URLs* are now resolved during rendering of links and navigation cases, and are now as functional as traditional mappings.

Bugfixes:

• Fixed bug that caused path parameter validators to be ignored (#102)
• Handle java.lang.ClassFormatError during initialization of bean name resolvers (#101)
• Also check Weld 1.1.x specific servlet context attribute while search for BeanManager
• Mapping inheritance now working correctly for mappings using the same viewId

* – Previously, DynaView URLs would only function on inbound requests, and once the method was evaluated, the value would be processed and then abandoned. For example, when rendering <h:link /> components, users would actually see the dynaview method definition rendered as their url! That is not a good experience, so in resolving the problem, we simple evaluate the dynaview method a second time (or as many times as necessary) in order to render the desired link target. And we do this using…

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.

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.

Here’s a simple tip for all of you AJAX lovers using JSF 2.0. It is possible to render components that live outside of the form where your AJAX tag lives; actually, it’s possible to render any component by using it’s fully-qualified component ID. Just prefix the target ID with the naming-container separator character, usually “:”, and provide the full name of the component as it is rendered on the HTML page.

It is amazing what can be done in exactly one year’s time.  January 17th will have been the 2nd anniversary since Lincoln Baxter and I started OcpSoft.  It’s been one seriously fun, and wild, ride with JavaServer Faces and the open-source community.  I want to take a moment to talk about my partner’s success story and what he has accomplished in just one short year.

As a vocal blogger, I feel responsible for promoting and sharing the good work of others, whether that be technology, creative work, or in this case: a book. I will take no exception to that philosophy when it comes to the JavaServer Faces framework. For a quick read, try the summary. If you are intrigued, read on! I hope you find this review valuable.

It was about one year prior to this article that I wrote “JSF2 is in good hands”, in which I spoke about the upcoming release of JavaServer™ Faces 2, and how the community had changed immensely in the few years I’d been using the tool. There were changes I wanted to make, and started making them by publishing an open source extension called PrettyFaces. PrettyFaces lets you map Pretty URLs to any resource within a JSF-based web-application (eg: /example -> /faces/examples/page.xhtml). While this is stuff that other web-frameworks have been doing for years, (WordPress, Rails/Grails, etc) it’s stuff that has traditionally been hard using JavaServer Faces – until around November 2008, when the first release was published. Now, I’m relatively new to this arena – I entered the open source community for the first time about four years ago, working on PHP and Perl modules. I’ve been using it, and appreciating it, for almost my entire life in the industry, but never giving back. I suppose one question that many people ask is, “Will working on open source software get me anywhere in my career?”