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.

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.

I’d like to start by saying that using JSF by itself can sometimes feel trying to pull your own teeth out with a pair of tweezers, but there’s hope. JSF was designed to be a platform of extensions – a foundation for building web-frameworks, and that it’s done very well. JSF 2.0 addresses most of the concerns about usability (so there’s less tooth pulling,) and provides even more extensibility. That’s where Seam Faces comes in, that’s where PrettyFaces comes in. On many occasions you might find yourself needing to compare the values of multiple input fields on a given page submit: confirming a password; re-enter password; address lookups; and so on. Performing cross-field form validation is simple – just place Seam’s <s:validateForm> component in the form you wish to validate, then attach your custom Validator.

Ever wondered why JSF doesn’t support bean @Inject-ion in Converters or Validators? Ever wondered how to listen to a single PhaseEvent or ComponentSystemEvent, or filter on events by componentId, or view? Ever wondered why you can’t just @Inject FacesContext, or NavigationHandler?

Well… now you can, with the brand-new, just-out release of Seam Faces — 3.0.0.Alpha3