The JSF 2 series on DZone we've been working on continues with an introduction to JSF 2 client behaviors by guest author Andy Schwartz. Andy is a member of the JSR-314 Expert Group (EG) and architect on the ADF Faces project team at Oracle Corporation.

In this installment, Andy introduces you to client behaviors for UI components, an API which he led, in collaboration with Alex Smirmov (Exadel), Roger Kitain (Sun/Oracle) and Ted Goddard (ICEsoft), to provide a general extension point for adding client-side functionality (i.e., JavaScript) to existing UI components. This new API quickly received support and input from the entire EG and proved to be a solid foundation on which the declarative Ajax control (i.e., <f:ajax>) could be based.

One of the goals of providing an extensible API is to encourage JSF users to leverage this for their own needs. While we only have a single standard behavior (<f:ajax>) today, we expect to see many third party behavior implementations in the near future. Some of these behaviors may be candidates for inclusion in future versions of the JSF specification – perhaps even yours!

We'd like to thank Andy for contributing his time and dedication in writing this article! Although Andy represents a different company than the other authors in this series, we come together as colleagues on the JSR-314 EG. The strong partnerships that are built between companies through their participation in JSRs are what make the JCP an asset to the Java EE community and allow the technologies to take such large leaps, in this case JSF. You can thank him too by rating the article.

I'm excited to announce that plans for a top-level JSR for the Unified EL are underway. It's likely that Kin-man Chung will be filing a JSR in the near future. But we aren't waiting to get the discussion started. Kin-man has started the open el-next mailinglist (el-next@uel.dev.java.net), where we will begin itemizing priorities and designing features. We'll then convert the requests into issue reports as they are solidified.

As you may know, the Unified EL is currently trapped inside of the JavaServer Pages 2.1 specification: JSR-245. While steps have been taken to free the dependency on JSP, the language still has a distinctive JSP spin. The fact remains that the EL simply cannot become a first-class citizen that works across the Java EE platform without graduating to its own JSR.

In an email, Kin-man defined the goal for the Unified EL JSR:

The goal for the JSR is to make EL a first-class citizen that is easy to use, both inside and outside of Java EE.

Red Hat's focus will be to make sure that the JSR is developed in the open and that as many of the feature requests we have or have heard from our community are incorporated into the specification. Those enhancements can be found on the EL wishlist wiki page.

Follow along with the mailinglist archives and watch this space for more details. You can request to join the uel project if you want to get involved.

I'd like to introduce to you the newest member of the Seam engineering team, Lincoln Baxter III. Lincoln has contributed (very vocally) to JSF 2 and developed a number of Open Source Java projects (such as PrettyFaces, PrettyTime and Scrum Shark). I'll take this opportunity to help you get to know him a little and share with you an abbreviated story of how he arrived at Red Hat.

Lincoln's interaction with the Seam development team started with one of those Can someone please take a look a this? e-mails from Gavin. It was Lincoln introducing his PrettyFaces extension for JSF.

I'm the author of the PrettyFaces extension. (...An explanation of how it works and what problems it solves in Seam...) My source is available here and is licensed under the GPL3. Most of what I think you'd be interested in will be in the PrettyViewHandler class, which is ... simple. Have at it. http://ocpsoft.com/prettyfaces

At around the same time Norman was developing a URL rewriting solution for Seam, so we didn't end up giving Lincoln much of a chance on this go around ;)

When Lincoln really started to catch our eye was when he posted on his blog that JavaServer Faces 2.0 is in Good Hands. In the blog entry, he highlights the impact Red Hat was having (namely Pete and myself) on the progress of the JSF 2 specification. He credited us as the first to really listen to the community and drive the spec in a direction that made the community feel assured and engaged. In short, he identified Red Hat as having leadership, and emphasized how important that quality is to him.

But we couldn't fill his entire vision. Lincoln had the false hope that Sun was putting effort into creating resources to help make the platform easy for newcomers to start using, in particular JSF, and that the JCP truly embraced openness. I had to let him down gently that both assumptions were a long way from reality (though since then Sun/Oracle has made a lot of important changes). I would learn from Lincoln's next move how much he really cared about making these perceptions a reality and whether he could affect change.

The fact that I'm writing this introduction gives away the answer.

A couple mornings later, the JSR-314 EG woke up and there was a new guy posting to the mailinglist...a mailinglist that was very difficult to get on (for a myriad of technical and political reasons). Lincoln found a way through. How? He became an individual JCP member, far from a simple task. He pleaded to Ed Burns to let him join the list and to be allowed to post. Gradually, people began to view him as an EG member and after many quality posts, everyone just accepted that he was an official member of the group. In fact, we would probably still be trying to find our own arse without him :) And good things are going to happen with him on board.

Since then, Lincoln has been a part of just about everything that has happened with the JSF EG. With my promise to Kito Mann and Jay Zimmerman that Lincoln would be among the best speakers at JSF Summit (despite having no speaking credentials), I got him into the conference to speak about his project, PrettyFaces. There he attended the JSF EG meeting, launched http://javaserverfaces.org--which he managed to convince Kito Mann to donate to the group--and sure enough, he gave the best talk of the conference (as decided by the attendees) in front of 12 EG members!

Right after JSF Summit, I contacted my managers at Red Hat and recommended that we hire Lincoln. I argued that we don't just want this guy to join our community, we want him to be a leader in our community. We certainly didn't want him to be stuck behind a desk fixing form fields any longer.

I could go on, but your break is probably over by now. Many of you will get a chance to meet with Lincoln at the next JBossWorld or interact with him in the JBoss.org community. One way or another, Lincoln is going to be one of the key leaders of our community, I guarantee it.

Good luck, Lincoln! And no pressure. Just do what you do best. Keep it simple!

In preparation for the release of Weld 1.0.1 on February 19th, we've pushed out a full distribution of Weld 1.0.1-CR2 for final inspection. It's based on the proposed CDI 1.0-SP1 API. Grab it, test it, play with it, give us feedback, let us know if it gets your stamp of approval. You can find direct download links at the bottom of this post or you can pull the artifacts from the Maven Central Repository.

For the Weld 1.0.1-CR1 release, we only published the Weld artifacts to the Maven Central Repository. We held off creating a full distribution until 1.0.1-CR2.

Missed JBoss AS 6 M2

Before we get to the release notes, it's important for you to know that this version of Weld will not be in JBoss AS 6 M2. You'll need to grab a JBoss AS 6 snapshot if you want the out of the box experience.

You also have the option of updating your JBoss AS 6 installation using this command from the root of the Weld distribution:

JBOSS_HOME=/path/to/jboss-as-6 mvn -f jboss-as/pom.xml

With that out of the way, let's look at what's new and noteworthy in this release.

Release notes

As you've come to expect out of this project team, this release (CR1 and CR2) includes major improvements in memory usage as well as numerous bug fixes (see the release notes below for details). We'll keep progress coming in these areas, as well as work on performance improvements in the Weld versions on the horizon.

Google App Engine

If you're a fan of Google App Engine (GAE), or just looking to experiment with it (using CDI, of course), we have really exciting news for you! Weld now has basic support for running on Google's scalable infrastructure. And just to prove it to you, we gave the Weld numberguess example its own appspot, where it's currently running. Go check it out!

If you want to get your own CDI + JSF 2 application running on Google App Engine, Shane Bryzak has done a fantastic job of showing you how to navigate the minefield to arrive at a successful GAE deployment. He takes you through App Engine signup, installation of the App Engine SDK plugin in Eclipse, the required CDI and JSF configurations and libraries and, finally, deployment in part 1 of his GAE tutorial series.

Props to the Weld community for working with the Weld project team to identify and patch assumptions in Weld that prevented it from running on GAE. While the basics now work, we still need help finding outstanding conflicts and getting them resolved in a way that does not compromise the compliance with JSR-299 or the integrity of Weld.

Weld SE

One area of Weld that we are particularly proud of, and which truly sets this implementation apart, is the Java SE support. The pioneering work done by Peter Royle and other community members will prove to be instrumental in shaping the future of the CDI specification as it extends outside of Java EE. Weld 1.0.1-CR2 brings improvements to the Java SE support, including documented support for interceptors and decorators and a refactoring to use the standard BeforeShutdown event. The most notable improvement is the simplification of the bootstrap API (i.e., new Weld()). I'll let the following code do the talking:

Weld weld = new Weld().initialize();
weld.instance().select(Foo.class).get();
weld.event().select(Bar.class).fire(new Bar());
weld.shutdown();

CDI TCK

The CDI TCK (1.0.1-CR1), which has also undergone a lot of improvements, will be included in this release. We'd like to thank the OpenWebBeans team for making the TCK more robust by identifying and helping to resolve deficiencies-ranging from broken tests to invalid interpretations of the spec.

In fact, we'd like to thank all the Weld community members who continue to find ways to improve the quality of the spec, the TCK and the implementation. Cheers!

Next steps

As mentioned above, the Weld 1.0.1 release is planned for February 19th.

Looking ahead, we plan to get to Weld 1.0.2 in 3 months time, focusing on performance, scalability and bug fixes. Developers eager to start adopting or migrating to Java EE 6 will be particularly excited to hear that we'll finally be shifting part of the team's focus to the development of Seam 3!

About Weld

Weld is used in GlassFish V3 and the JBoss AS 6 series. Weld also has support for Servlet containers such as Tomcat and Jetty. While JSF support is built in, you also have the option to use Wicket as your view layer or even Swing and JavaFX through the Java SE support. If you are an OSGi fan, there's a bundle for that too.

If you are just getting started, there are a few examples in the distribution to guide you (look for instructions in the reference guide, and each example has a readme.txt). If you are looking for help, try our user forums, or perhaps join us on IRC.

[ Weld Distribution ] | [ Release Notes (1.0.1-CR1, 1.0.1-CR2) ] | [ Reference Guide ] | [ Issue Tracker ] | [ CDI Javadoc ]

The initiative to create Weld archetypes has had a further reaching impact than just the community of developers interested in using CDI (via Weld). A recent entry on the Sonatype blog, titled Maven Archetypes and Nexus: “There is No Faster Way”, cites the Weld archetypes as:

...the perfect case study of how using Archetypes benefits the community.

Steven Boscarine (Weld community contributor) is applauded for recognizing the value archetypes can bring to the community and for ultimately getting them promoted to Maven central for all to use.

Although archetypes are rather technically simple, it's important to recognize the impact they can have by starting people off on the right foot.

By the way, we are still looking for contributors that would like to help shape the vision for the Weld archetypes, and to get us from beta to a stable release.