Winner of the JSF Spec Logo Contest: Wilber Saca
Use Instant Runoff Voting to pick your favorite JSF logo at http://bit.ly/JsfLogoPoll
I relate a quick story about a Mojarra code review that was gratifying.
In November, Servlet 3.0
Specification Lead Rajiv Mordani, and I started providing technical
advice to the team at Sun developing the successor to the Sun
Certified Web Component (SCWD) certification exam. This new exam
covers Java EE 6, including JSF 2. All this week, the work will
continue in the form of an offsite workshop at the
To help ensure the highest quality exam possible (and...
I've read the Amazon Cloud outage blog entry
You can see that JSF+CDI and multi-component validtion are the two
big winners, followed by resource handler improvements and a feature
that seems like taking the composite components to the next level:
support for composite applications.
Make a logo for the JSF specification. Win the contest. Contribute it under the Oracle Contributor Agreement. Get a free book, if you want it.
Help us organize our open issues for JSF 2.2 by voting for your top five issues.
As mentioned earlier and elsewhere, JSF 2.2 is getting started right now. This blog entry is a call for serious, committed participation in the JCP Expert Group dedicated to delivering that specification.
Here's a look at a draft of the JSF 2.2 JSR we plan to file with JCP.
Mojarra 2.1.0-b11 will likely be the final release of 2.1.0.
Ed announces release candidate 1 of Mojarra 2.1.0.
The Mojarra JSF Developer community can now know when it is safe to check in to the Mojarra source code repository.
In order to bring the testing matrix for Mojarra more in line with Oracle’s current engineering investment, we are planning to have all future Mojarra builds that are targeting the upcoming JSF 2.1 specification only support JavaSE 6 and beyond. Any 2.0.X and 1.2 builds will still continue to be built with Java SE 5.
I ask for people to share their thoughts on what wastes time during development with JSF.
At the very beginning of my full time programmer career, when I worked at Silicon Graphics, Larry Wall and Randal Schwartz gave a brown bag session about their now legendary camel book. Naturally, I had them sign my copy, the front page of which I proudly display at left. Notice the “There’s More Than One Way To Do It!” stamp at the top. For better or worse, Perl is famous for this property. Less famous (or perhaps even infamous) for having more than one way to do it is JSF.
At the JSFdays conference last week, I was having lunch with a friend who is an experienced developer and the topic turned to JSF deployments in large projects. He mentioned that his project was bitten by the fact that there was more than one way to do it in JSF. If you give developers more than one way to do something, they'll take advantage of that capability. But, in a large project with many developers, this can lead to confusion and unmaintainability.
The simplest remedy is to establish firm and strong conventions for how to do things for which there is more than way one to do it. Of course, this is easier said than done, but I believe, as do Wall and Schwartz, that having more than one way to do it is generally an asset rather than a liability.
Reference to correct post at <http://weblogs.java.net/blog/edburns/archive/2010/01/22/analysis-peter-thomass-jsf-critical-rant>.
Ed shares his thoughts on a blog entry that is very critical of JSF.
I provide an annotated extract of Sebastian Hennebrueder's JS2 Evaluation and Test blog entry.
Ed responds to Byrne and Sulaycki of SpiderLabs about their upcoming BlackHat presentation about view state security in JSF.