Editor's Desk

Tuesday Apr 23, 2013

JSF 2.2 Final Draft Approved; Java EE 7 Coming Soon


JavaServer Faces 2.2 (JSR 344) was officially approved on April 18th last week. The results were unanimous, with the exception of a couple of members whose voting rights were suspended (such as Google), and a couple that didn't vote (such as Nokia). JSF 2.2 is part of the Java EE 7 release train, which includes a bunch of other JSRs:

  • Java Persistence API (JPA) 
  • Java API for RESTful Web Services (JAX-RS) 
  • Servlets 
  • Enterprise JavaBeans (EJB)
  • JavaServer Pages 
  • Expression Language 
  • Java Messaging Service (JMS) 
  • Java API for XML-based Web Services (JAX-WS) 
  • Contexts and Dependency Injection for Java EE (CDI) 
  • Bean Validation 
  • Common Annotations (JSR-250)
  • Java Connector Architecture 

There are also a few new JSRs in Java EE 7:

Personally, I'm particularly excited about having a standard API for JSON processing and WebSocket. All of these JSRs have either been approved, or are in the final review stages. According to the Java EE 7 schedule, all of the JSRs are expected to be approved by the end of the month, and the reference implementation (Glassfish 4.0) should be out in the middle of May.

So, what about JSF 2.2? First, keep in mind that even though it's part of Java EE 7, you can still use it without the rest of the release train, although it now requires a minimum of Servlet 3.0 (which ships with Java EE 6 containers). That being said, some new features require CDI. This means that Spring shops will have to roll their own integration with Spring for these features, much like they must do today in order to support JSF's view scope with Spring.

Even though JSF 2.2 is a point release, it includes a few major features, plus several other enhancements and bug fixes. Even though HTML5 has always been supported, it's easier than ever with HTML5-friendly markup (you can now build JSF pages using HTML syntax instead of component tags). Faces flows allow you to package up navigation, pages, and code into easy-to-manage modules. Enhanced Cross-Site Request Forgery (CSRF) protection makes your applications more secure, and finally there is a standard File Upload component. Resource library contracts allow you to swap sets of templates, images, stylesheets, and JavaScript files across your application, simplifying customization for different clients or deployments. Other features include loading Facelets via the ResourceHandler, view actions, and window scope.

We'll be covering more of JSF 2.2 here at JSFCentral.com, but if you want to play with it, you can always check out the most recent Mojarra (reference implementation) snapshot (download it, or specify the Maven dependency). MyFaces isn't too far behind with their support either.

 

Tuesday May 05, 2009

Where are the Conversations?

First, I want to say I'm extremely excited about JSF 2.0, and I think it's a major leap forward for the framework.

That being said, there's one thing that's been bugging me for a while: no built-in support for conversation scope. (For those who don't know, "conversation" scope is shorter than a servlet session and longer than a request, and is popular in frameworks like Seam, Spring Web Flow, MyFaces Orchestra, etc.).

By default, JSF 2.0 will leverage the controversial JSR 299 (Java Contexts and Dependency Injection, or JCDI) specification (formerly WebBeans). JCDI provides, among other things, support for conversations in a JSF environment. Both JSF 2.0 and JCDI will be part of Java EE 6, but users of existing containers will have to download a JCDI implementation, such as WebBeans, just to use conversations.

Good luck if you only want to use conversations -- JCDI adds quite a few other features which, although powerful, add conceptual complexity.

On the bright side, JSF 2.0 supports custom scopes, so adding conversation support is something frameworks like MyFaces Orchestra can add (developers can easily add their own scopes, too). But, then again, why do frameworks need to add support for something as common as a conversation scope? To me, and many people I've talked to such as Matthias Wessendorf, this seems like a natural fit for the Servlet spec. And, for all of the useful features in Servlet 3.0, this one is sorely lacking.

So, here's the bottom line:

Conversations should be part of the Servlet spec.

And remember, I'm saying this as a member of both the JSF 2.0 and JCDI expert groups. Once again, a key part of the Java platform is not implemented consistently across different layers of the stack...

Calendar

Feeds

Search

Links

Navigation

Referrers