And I think what I'd like to do is..RichFaces has a very long history, started out as a product with Exadel and then has been with JBoss for quite a few years now.

And I was just wondering if you could kind of give us an overview of what happened with RichFaces 4.0 because that was the last sort of major release. And I think a lot of people have worked with 3.x or have seen an older version of RichFaces, and may not be kind of familiar with the changes in 4.0. So, why don't we start with that, and then we can talk a little bit more about the newer releases, especially 4.2.

And along with that, we have a couple new features that we introduced with RichFaces 4.0. We have the client side validation feature, which brings bean validation into the browser with a JavaScript implementation. So, you can get feedback-users can get feedback on validation errors right within their browser. And similarly, we introduced the push feature with RichFaces 4.0 based on the Atmosphere Framework.

We also...in RichFaces 4.1, a big feature for us was the introduction of a mobile compatibility layer for our components. We did the appropriate tweaks and improvements to our components, so they work well in a mobile environment. You can see this if you go to the RichFaces showcase with your mobile-enabled browser or your browser on your mobile phone, and view the showcase. You'll see the mobile version of the components, and how you can build mobile applications with our existing components.

After releasing RichFaces 4.1, we found there were some components and some feature improvements that were missing from RichFaces 4.1 that really needed to be in the hands of developers. So, we decided to get a rush on those improvements, and improve capabilities and get RichFaces 4.2 out as soon as we could.

So, we improved this in RichFaces 4.2. We separated out the concept of mapping JSF resources and packaging and compressing those resources. So, what one can do now in RichFaces 4.2 is...for instance, a lot of different JSF components, or even JavaScript widgets- vanilla JavaScript widgets-are taking advantage of jQuery as it becomes a de facto standard. Well, RichFaces bundles jQuery for use with its components. And when you start using all these different component libraries and widget libraries together, you get conflicts...each one trying to load jQuery, and then jQuery just becoming unhappy with that scenario.

So, with RichFaces 4.2 resource mapping feature, you can intercept all those requests for the jQuery resource, and map them to a particular file or a particular resource that you want to serve, which would then get only served once. So, that's a great use case moving forward. Another one is if you need to patch JSF.js, if you found some bug or some improvement that you wanted to patch yourself, you can provide that component. And with a simple entry in a mapping file, you can have your resource served up instead of the one bundled with the JSF implementation.

So, those are some great improvements to the feature that we've introduced in RichFaces 4.2. We still have the packaging minification steps that we introduced in 4.1 that you can do subsequent to that mapping.

So, one area where we did that is with the push component. If JMS is available, you can have the push feature, use JMS queues for the messaging implementation. So, this is a great way of taking advantage of these high-power server side features that you have without a lot of work for the end user, or the application developer.

Another place where the push component integrates with other Java EE technologies was with CDI. In RichFaces 4.1, we introduced a CDI API to allow one to create messages and push them to the browser using a CDI event mechanism.

We're looking at improving-always looking at improving. But physically, we're looking at improving our testing infrastructure in the coming months, and the coming releases. So, if you're at all interested in the topic of JSF testing, now is a great time to stop by our forums or weekly IRC meetings, and you can get involved with what we're doing, and look at testing the JSF applications.

And in particular, the CDK in RichFaces 4.0 is really built on...it's built to have the feel of the JSF 2.0 composite component feature or technology, where one builds renderers using Facelet templates, rather than writing the Java classes. So if we look at the big picture of creating a component with the CDK, one defines a component as a class, and then you define the properties in the class, and you annotate them with this attribute annotation. And that's all you have to do to define the component. To define the renderer, we create a template file that uses the JSF 2.0 composite component templating feature as a basis, but builds on top of it with some CDK-specific extensions.

And those two files are all that's required to create a full-fledged JSF component. The CDK, at build time, will analyze your component and the annotations and what you put into that template file, and build all the required Java classes and .xml files, and all the fluff that's required to get a JSF component going. So, it's a great way to provide a new JSF component that's a full-fledged component, not a composite component.

And I have spoken with some individual users who have come across some bugs or limitations in the JSF 2.0 composite component technology or feature, whatever we should call that. But they were able to get around with by using the RichFaces CDK.

What have you heard in terms of your users with using other component suites? Do you feel like it's gotten any better? Or do you feel like it's about the same? Or what?

So, a lot of the error reports we get from people trying to mix libraries, come out of this jQuery/ JavaScript layer. So, it sounds like a lot of the problem is that the JSF 2.0 interoperability issues have been resolved, but I think a lot of that is being limited by these jQuery/JavaScript errors. And so, if we can get past that, if our resource mapping feature allows people to get past that, maybe we'll get more people exploring how the different libraries fit together. And then, we'll start to get better feedback on the JSF 2.0 improvements in that regard.

So now moving forward with RichFaces 4.0, we're going to continue to make improvements to those components. We're going to fix bugs. Some of the features-while the component is present in RichFaces 4.0, in some cases a particular feature hasn't been implemented from RichFaces 3.0-we're going to continue to make those improvements.

But what we want to look at in addition to that effort is providing a new set of components with RichFaces 4.3 and beyond. So in today's world, as everyone's probably aware, JavaScript and JavaScript widgets, as I call them, are really taking off at a fantastic pace. Projects like jQuery UI, and well there's a whole number of them to list, are providing web developers with JavaScript components that they can use in their applications to build very rich user environments, in much the way that JSF component providers have been doing for a number of years. But these are now JavaScript isolated components.

So, what we want to be able to do moving forward is take advantage of that whole ecosystem of JavaScript widgets, and wrap them using the CDK to provide full-fledged JSF components for end users. And so in this way, we hope to be able to improve our turnaround of providing users with new rich functionality in their components.

You're also the module lead for Seam Faces, which I imagine you spend fewer hours on than RichFaces. So, you mentioned the view actions. Could you just explain that and just a couple of other key features in Seam Faces?

So for instance, you can-based on the URL or query string parameters that you're using to access the page-initialize certain backing beans, check for authorization, perform a navigation to another page. You can enable all those with the viewAction, without having to do it at the Java code level, you can do it within the viewAction Facelet tag.

So, some simpler developer productivity improvements are facilitating working with CDI conversations and JSF backing beans by providing the annotations @Begin and @End. So you can annotate a method with @Begin, and when that method is executed, you will begin a CDI conversation, instead of having to inject the conversation and programmatically execute Conversation.begin, and so on. And there's the analogous @End annotation, which says when this method is executed, I want you to end the conversation.

Seam Faces provides generic converters. So, this has nothing to do with CDI, but it's just a developer productivity improvement of making life easier for a JSF developer. When you write a JSF converter, you always find yourself doing a cast, right? Because you're working with objects and converters. Well, we provide some generic converters that do that casting for you. Just to make things easier.

Moving onto some of these bigger features, what I might even call the killer features of Seam Faces, we have this view config feature in Seam Faces, which is that replacement for the pages .xml you were referring to from Seam 2.0.

Bringing it back to CDI, Seam Faces allows CDI injection in more JSF classes. So, in your converters and your validations, you can take advantage of CDI injection there.

Moving on to some of these bigger features, what I might even call the killer features of Seam Faces, we have this ViewConfig feature in Seam Faces, which is that replacement for the pages.xml you were referring to from Seam 2.0.

But the advantage of ViewConfig is that it's a type safe way of configuring your JSF views. So, if you think of the improvement of CDI over Seam 2.0 is the introduction of type safety, the ViewConfig then gives us a type safe way of configuring our views that we did not have with the pages.xml. Some of the current things you can configure with this ViewConfig -it's very much annotation based-are security, you know, controlling access to your views by leveraging the Seam security module; you can do URL rewriting when you access the page, leveraging PrettyFaces; you can control the transactional behavior of that page by leveraging Seam Persistence; and you can even do something so simple as turn on faces-redirect for a view or a set of views using an annotation of the ViewConfig level, so, you don't have to write faces- redirect throughout your application.

So, it's a great way to take advantage of the exposure of the API that JSF gives without a lot of overhead to the end user.

So, I assume you're very familiar with DeltaSpike, more than me. Do you want to give us an overview of that and how that fits in with Seam Faces?

And the idea is to create this set of de facto CDI extensions that other projects that can then build on. We've just released the 0.1 release of DeltaSpike, which incorporates some features from Seam Solder and CODI Core to provide the basis of building further extensions. And the goal is to take all that functionality-you mentioned the duplication of functionality between MyFaces, CODI, and Seam Faces as a particular example-but we want to take all this overlapping functionality and put it into DeltaSpike as a common core, and build on that as a set of extensions that everyone can use in their project. So, we're going so far with that ourselves, that we're not going to be doing any more Seam 3.0 releases. We're focusing entirely on DeltaSpike right now.