If you haven’t yet heard about it, JBoss Forge is a fantastic new tool from JBoss for rapid application development of standards based applications. Forge allows a developer to quickly set up the scaffolding for an application, and quickly get to the matter of solving domain problems. What makes Forge particularly interesting, from my perspective, is the way it was built with plugins in mind as a defining way in which the platform is meant to be extended.
In Seam Faces we’ve provided JSF developers with a mechanism to centrally configure various aspects of their JSF views. Concerns like transaction control and view security are currently supported, and support for URL rewriting, XSRF attack prevention, and JSF navigation is in the planning stage. The end-goal is to support view configuration via multiple sources (including some support for <f:metadata> child tags). For now we provide type-safe configuration using annotations on enums.
Like any piece of software, Weld, the reference implementation for JSR-299, is continually improving as bugs are discovered, and performance is optimized. However, since Weld is tightly coupled with your application server of choice, using the latest weld is slightly more complicated than just bundling a weld release with your web application. This post outlines the relatively painless process of updating the Weld implementation of Glassfish 3.1 to use the latest SNAPSHOT, or any later release for that matter.
JSF 2 introduced the ability to create RESTful URLs with the introduction of the <f:viewParam> tag. The tag is easy enough to use, you simply place it in the <f:metadate> tag, and configure the attributes to decode the url. <f:metadata> <f:viewParam /> </f:metadata> There are no words to explain how great a feature this is for JSF. The old “every request is a POST” theory didn’t pan out. RESTful URLs are bookmarkable, and meaningful to end-users.
At first the conversation scope introduced with CDI seemed like it would be incredibly useful. Unfortunately, working with conversations ended up being more difficult than expected. Details of why this is, is fodder for another post. I ended up often using the JSF ViewScope, exposed as a CDI scope though the Seam Faces CDI extension. When used in conjunction with JSF viewParams to propagate information between pages, the result is a book-markable end user experience.
CDI is the new programming model introduced with Java EE 6. An acronym for Contexts and Dependency Injection, CDI advertises well two of the programming paradigms it aims to solve. But there is another, often overlooked sibling: Event handling. While I’d heard it mentioned in the context of CDI, I’d never really paid much attention - I was probably too busy trying to wrap my head around Conversations, and how CDI provides Dependency Injection.
Call me eager, call me insane, I had a JavaEE 6 app up and running in production on Glassfish 3.0 one month after it’s release. The improvements in JSF 2 and CDI were too compelling for me to hold off adopting, and sure enough, the application was quick and painless to develop. I did however pay a price for being an early adopter - a Glassfish / Weld bug was preventing my JSF login pages from working.
Here’s how I show a notice on a JSF 2 page indicating that the JSF 2 postback failed due to validation errors. The following facelet snippet is rendered only when validation fails: <h:outputtext styleclass="errorMessage globalMessage" value="Request not saved due to input errors" rendered="#{facesContext.validationFailed}" /> The user then knows they should look through the page to correct the individually marked validation failures.
I’ve been toying with the idea of moving from svn to a distributed version control system (dvcs) for a long time. I held back, hoping the mercurial (hg) vs. git “war” would declare a winner, but as major projects started adopting the two dvcs’s, it became apparent to me that neither tool was going to disappear anytime soon. This notion was cemented for me when I read a forum post saying hg = git >> svnThat settled it.
I’ve jumped on the JavaEE 6 bandwagon, with one application already in production. The developer productivity improvements in JavaEE6/Glassfish V3 are tremendous. The only downside is that I still have some JavaEE 5 applications in production. The JavaEE 5 apps can’t migrate to JavaEE 6 until Icefaces supports JSF 1.2. One workaround to this is to bundle the JSF 1.2 implementation with your application, then configure the classloader using the sun-web.
