|Kito|| Hello and welcome. My name is Kito Mann. I am the editor in chief of JSFcentral.com. And
today is-what's the date here? Oh yeah, February 15th, 2012. And today, I'm doing a Skype
podcast interview with Brian Leathem who is a senior software engineer with JBoss by Red
Hat, and he's a RichFaces core developer and also the module lead for Seam Faces. Hello,
|Brian|| Hi, Kito. How are you doing?
|Kito||I'm doing well. How's the weather treating you? Where are you located, anyway?
|Brian|| So, I'm in Vancouver, Canada, on the West Coast. And we seem to have started with some
rainy spring weather lately.
|Kito||Ah, but you said spring though, so that's a good sign.
|Kito||Yeah. It's been kind of mild here, I'm actually on the East Coast. I'm near New York City, and
it's been kind of-you know, I think it's been like really cold a little bit, but mostly mild. So, who
knows? I'm looking forward to spring.
|Brian|| That's right. And the following summer
|Kito||Yes. Indeed. I bet you it's really beautiful there in the summer, I would imagine.
|Brian|| Yeah. Vancouver is great.
|Kito|| Yeah. Cool. Well, I wanted to talk about a couple things here today, which relate to what you
do. So, let's start out with updating people about RichFaces, I know you guys are releasing
RichFaces 4.2 right now. I think CR1 came out on the 8th. And by the time you hear this, 4.2
will probably be final.
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.
|Brian|| Sure. Sounds good. So, RichFaces 4.0 was primarily focused on supporting JSF 2.0. So with
JSF 2.0, of course, we saw the standardization of the Ajax approach in JSF, and a
corresponding change in a number of the APIs that component developers used to build
components. So, with RichFaces 4.0 we ported a number of the RichFaces 3.0 components to
work with JSF 2.0 and allow application developers to make a smooth transition from
RichFaces 3.0 to RichFaces 4.0.
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
errors right within their browser. And similarly, we introduced the push feature with RichFaces
4.0 based on the Atmosphere Framework.
|Kito||Oh, okay. So, there was an a4j:push component before, right? But did it use polling internally?
|Brian||Yeah. So, what's new with RichFaces 4.0 is being based on the Atmosphere Framework,
which will even go so far as to take advantage of web sockets when web sockets is available.
|Kito||Cool. Alright. So, that was for-and I think that was what, in 2011 or 2010, maybe?
|Brian|| That would've been May 2011, I think was the date. So, we're coming up on a year.
|Kito|| Okay. Wow. So, you guys move fast, and they're all ready for 4.2. Alright. So, 4.1, was it just
a maintenance release? Or were there any new features or anything?
|Brian|| Right. So, with RichFaces 4.1, we introduced some more components that we ported from
RichFaces 3.0. We brought in the rich editor component, which had been missing, and the pick
list and ordering list. And in fact, with RichFaces 4.1, we've replaced the RichFaces 3.0
ListShuttle component, which a lot of RichFaces 3.0 users will be familiar with. We've replaced
that with the RichFaces 4.0 PickList all together. So, some simplification of the components
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.
|Kito|| Now, here's a question for you while we're on that mobile topic. Do the components...do they
automatically change based on the client? Or is it something that the developer has to code to
say: okay, if it's a mobile device, then show this particular page reduces these components.
|Brian|| Right. So, we have a whole getting started guide with RichFaces mobile that'll lead you
through that. And you have to include some additional CSS resources when you're serving up
a mobile page. What we like to look forward to in forthcoming RichFaces releases is creating
platform specific renderers that would take care of this for you automatically. But some R&D
work is required there.
|Kito|| It looks like you're mostly targeting phones here. Are you targeting tablets or anything as well?
Or just mostly the mobile phone footprint?
|Brian||Well, it's significant with our mobile compatibility of these components...it's making them
enabled for touch devices. Making the buttons big enough so you can get your finger on them.
Making sure they render and behave appropriately in the different environments. And we do
test on both phones and tablets, so there's nothing specific to phones in here.
|Kito|| Okay. Cool.
|Brian||So, getting back to what's new in RichFaces 4.1, there are a few more things I'd like to
highlight. One is we moved our code base to GitHub, which is a significant change from SVN,
for those of you who are familiar with GitHub. This speaks to the community nature of the
RichFaces project, and how we really want the community to be involved. And we find GitHub
is-it's a great tool to enable that. Empowering end users to make poll requests...if they want
to change or contribute to the framework.
|Kito|| Have you gotten a lot of participation or more participation since you made the move?
|Brian|| Yeah. We have gotten some community poll requests, which is great. I don't know how many
of those were enabled specifically through GitHub, if they would've contributed through the
SVN and patch process before. But it definitely lowered the barrier for them, made that easier.
|Kito|| Right. Right. I know in the past, I always like-whenever I've made a change I'm like "oh man,
I have to make a patch and add it to the..." it just seems like a major pain.
|Brian||Right. Whereas GitHub's got a big GUI button to make that easy for you.
|Kito|| Right. That's nice.
|Brian|| We've also moved the showcase to running on the open shift platform by Red Hat, which is the
Red Had solution for virtualized platforms.
|Kito||Yeah. I've been meaning to take a look at that myself. We actually use Amazon EC2 for all the
JSFCentral related stuff.
|Brian|| Yeah. OpenShift at some level-as you move up into the Flex tier of it-is running on Amazon
EC2. So, it just provides a nice management interface for you to deal directly with your
application servers, and not worry about managing the operating systems in the cloud. I'm not
an expert to be speaking on OpenShift, but it's a significant change for us.
|Kito|| Yeah. That's cool. And I remember in the old days, the RichFaces demo app was kind of slow.
So, it's probably a lot speedier now. I think it was just whatever machine it was on, like a long
|Brian|| Yeah. In the RichFaces 3.0 days?
|Kito|| Yeah. Yeah. Exactly. Was that all for 4.1? Or was there something else you wanted to
|Brian|| Yeah. Yeah. Exactly. Was that all for 4.1? Or was there something else you wanted to
|Kito|| Okay. Well, let's move on to kind of the core of your focus, then. Because 4.1 came out in
|Kito||Wow. You guys do move fast. Okay. So now it's February, and we're talking about 4.2.
That's really cool.
|Brian|| Our goal for our pace there was to have a six-month time block release, so developers could
count on when RichFaces releases are going to come out and plan accordingly. You know, not
restricting ourselves to a six-month time block, but that was our goal.
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.
|Kito|| Cool. So, looks like there are actually quite a few things in 4.2. Do you want to go ahead and
start with that?
|Brian|| With RichFaces 4.2, we've introduced some more components ported over from RichFaces
3.0. We have the context menu component, and the hotkey component, which were both
missing in the RichFaces 4.0 releases up until 4.2.
|Kito|| At this point, have you ported the entire component set or are there still RichFaces 3.0
components, which have not been ported yet?
|Brian|| There are some additional components that have not been ported forward. And some of them,
we never will port. At some point, they start solving narrowly small use cases, and our time
would be better spent developing new components that solve new use cases. But we're really
in tune with our community here, listening to feedback, and making good use of the JIRA voting
mechanism, for instance, to help our community identify which are those RichFaces 3.0
components that they would like to see move forward.
|Kito|| Okay. Cool.
|Brian|| Also, with RichFaces 4.1, we've seen some-with RichFaces 4.2, sorry...there's too many "4
points" going around here. With RichFaces 4.2, we've seen some improvements to the push
and resource optimization features. Lukas Fryc has excellent blog posts going into details
there, which I can provide links to.
|Kito|| Well, just take a step forward there...what do you think are the key changes that were made?
If you were using the older one, why would you care?
|Brian|| Sure. In RichFaces 4.1, we introduced our resource packaging feature, which combined all
one to dramatically reduce the amount of resources that-when downloaded-when running
JSF or a RichFaces application.
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
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
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.
|Kito|| So, for packaging, does that mean that you could have one huge RichFaces.js file or
something? Or is it just more about how you associate the resources for a particular
and one CSS file for each component they use on the page, you'll download a single pack.js or
pack.css file that includes all the resources for all the components. So, you get a single
download, which would then be cached by your browser and used on subsequent pages. So,
you wouldn't invoke additional downloads using your application.
|Kito|| Okay. Cool. For the push stuff, I just wanted to move back to that for a second. Can you just
mention some of the highlights? Because it looks like there's some JMS integration in there,
which sounds really cool.
|Brian|| Right. That's a...I feel, a strong feature of RichFaces is our commitment to open standards,
both in contributing back to improving the standards, and also enabling the developer to take
advantage of other Java EE standards as we can.
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.
|Kito|| So basically, one option would be like you have JMS queue setup, and I guess one of the
endpoints is essentially the webpage, right? You could update whatever parts of the page or
whatever components based on the JMS queue. In a non-Java EE environment, where say
you're using a web profile or something, how does the push work? How do you basically push
data back to the client?
|Brian|| So, in most cases, pushp-the data's pushed back to the client using the Atmosphere
Framework. But when you're using JMS, the messages you want to send back are queued in a
JMS queue. So, you get the fault tolerant-all the goodness, if you will, that you get from the
JMS technology. When you don't have JMS in your environment, you don't enable that feature.
Then the messages are just sent directly via the Atmosphere Framework down to the browser.
|Kito|| Okay. So basically, you don't have a queue either, right?
|Brian|| Well, there is a queue to push those down, but it's not-let's see if I can remember. What
makes the JMS queue special is it'll survive-if you pull the plug on the server, the JMS queue
will guarantee that those messages propagate, or will continue to be delivered. There's a term
for that is escaping me right now.
|Kito||Yeah. I know that there is, too. But yeah, I don't remember it.
|Brian|| So, that's what you get when you enable the JMS queue to back the push component. But of
course, if you don't have JMS available, you're in a servlet environment or something like that,
you don't have to take advantage of that.
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.
|Kito|| Oh, okay. And for those of you who still aren't aware, CDI is the Context Dependency Injection
for the Java API, which is part of Java EE6, and can also run outside of the Java EE container.
Okay. Cool. Let's see, there's also, I guess, skinning improvements that you guys have made?
|Brian|| Yeah. In RichFaces 4.2, this was a feature that came from a community poll request, to
provide a rounded corner support to the standard RichFaces skin. By simply enabling, or
setting the value on a RichFaces skinning parameter, you can turn on round corner supports,
taking advantage of the CSS 3 round corner...what is it...border radius property.
|Kito|| Okay. So, were there any other things you wanted to highlight in 4.2?
|Brian|| No, I think we covered what's new in 4.2. So, 4.2 was hot on the heels of 4.1. And we really
focused on getting those new components in and those API improvements, and both the
resource loading and the push capability.
|Kito||Were there a lot of bug fixes initially? Or is it just mostly those new features?
|Brian|| Oh yeah. There were definitely some bug fixes. There are always bug fixes to make with
every release. As users-new users-try new components and new use cases, there's always
something that comes up. We do have a strong quality component to the RichFaces project,
which is another one of its strengths. We have a dedicated QA team that with every release
runs a battery of tens of thousands of tests to guard against regressions and so on.
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
|Kito|| Yeah. And I think what you guys have done on the testing side has been very cool. Because I
remember talking to Jay about this, Jay Balunas. Is he still the lead project manager for
RichFaces? Or is someone else doing that now?
|Brian|| Yeah. So I'm now leading the RichFaces project.
|Brian|| Jay has moved onto the AeroGear project within JBoss, which is looking at mobile technologies
as a whole, across different web frameworks and throughout the entire application
development ecosystem, if you will.
|Brian|| So, he's still involved with RichFaces, particularly when it comes to mobile concerns. But he's...
|Kito||He's no longer doing day-to-day operations with it.
|Brian|| Yeah. That's a good way of putting it.
|Kito|| Okay. So, I remember...in sort of the earlier days, testing was not nearly as rigorous as it
seems to be now with RichFaces. So, it seems like you guys have come a very long way in
terms of getting a really, really powerful automated suite together.
|Brian|| For sure.
|Kito|| And actually, it reminds me of one thing. One thing I did want to ask about is the RichFaces
Component Development Kit. It's probably not as well known as the project itself. Do you want
to just give a quick overview of what that is?
|Brian|| Sure. So, the CDK is the tool that we use to write our RichFaces components. This was
available in both RichFaces 3.0 and RichFaces 4.0, but with RichFaces 4.0, we've seen a
significant improvement in the usability of the CDK.
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.
|Kito|| Yeah. I think the key thing I wanted to point out is that the output is not a composite
component, even though the way you develop it is like a composite component.
|Brian|| That's correct.
|Kito|| Right. Cool. Have you found that many of your users are actually using the CDK? Because I
know you guys have been-you know, you wrote some documentation about it, you've been
blogging about it to try to get people outside of the development team of RichFaces to use it.
What have you actually seen?
|Brian|| Okay. We have definitely seen some use cases where users have used it. Some of our users
are developing RichFaces components. We have this sandbox environment where users are
welcome to contribute the components they developed. So definitely some CDK uptake for
those contributing there.
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.
|Kito|| That makes a lot of sense because there definitely are some limitations once you start doing
some more complicated things. Now is the output, is it dependent on RichFaces resources,
like RichFaces objects and classes?
|Brian|| Yeah. It takes advantage of a lot of RichFaces based classes in the output that it generates.
So, you will need RichFaces run core and component libraries available.
|Kito|| Okay. Cool. There's another thing I wanted to ask you, with...well, there's probably many
other things I want to ask you. But one of the other things along sort of the random RichFaces
questions line is...with regards to JSF component interoperability. I know that was one of the
things we tried to focus on enabling in JSF 2.0. And I know before 2.0, before JSF 2.0, there
were always a couple component suites that could work together. You know, you could use
RichFaces with PrimeFaces or RichFaces with Trinidad. But you couldn't use RichFaces,
Trinidad, and PrimeFaces or anything like that.
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?
|Brian|| Well, that's interesting because I do get a lot of feedback about people trying to mix component
layer. A lot of the JSF component suites these days are taking advantage of jQuery as it's
becoming this de facto standard. And as I alluded to earlier when I was talking about the
RichFaces 4.2 resource mapping, jQuery conflicts can come up when jQuery is included and
initialized more than once, and so on.
So, a lot of the error reports we get from people trying to mix libraries, come out of this jQuery/
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.
|Kito|| That's a good point. I mean, I think we did try to do some of that with the resource handling
features in core JSF 2.0. And I imagine that some of the things you do build on top of that.
|Brian|| Definitely. Definitely building on top of what's available in JSF 2.0.
|Kito|| Now, in terms of dependencies, is jQuery the only sort of third party dependency? Or are there
|Kito||Cool. Okay. Trying to think if there was anything else along the whole RichFaces line. I guess
I was wonderingI'm looking actually at your roadmap here-and it looks like it says "roadmap
and planning for RichFaces 4.3 and beyond." And I must admit, one of the great things about
RichFaces is that you guys are so transparent with your planning and your releases and
|Brian|| Openness is very important to us. That sense of community. We want to be involved with the
community as much as we can. We even go so far as to have our weekly meetings held in the
open on IRC. And anyone's able to come and participate or even speculate. We have some
regular spectators who just want to know what's going on with the project. And they find that a
great way to get their finger on the pulse of what's going on with RichFaces.
|Kito|| Yeah. And isn't that sort of how you got involved with RichFaces? Sort of from the community
to begin with?
|Brian|| Definitely. I initially got involved with the Seam project, and I got involved in there through the
community. I had an itch I wanted to scratch, a bug I wanted to fix. I put in the patch and
things quickly escalated from there. So, that community involvement is definitely a key concept
that we hold dear. It was one of the principles of our project, for sure.
|Kito|| Yeah. That's really cool. So, just looking ahead for RichFaces 4.3 and beyond, can you kind of
give us an overview of what things you guys are looking at?
|Brian||Right. So today, our efforts have really been focused on moving RichFaces 3.0 to RichFaces
4.0-getting that component capability, enabling users to move their applications from
RichFaces 3.0 and JSF 1.x into RichFaces 4.0 and JSF 2.0.
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
UI, and well there's a whole number of them to list, are providing web developers with
environments, in much the way that JSF component providers have been doing for a number of
So, what we want to be able to do moving forward is take advantage of that whole ecosystem
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.
|Kito|| Okay. Cool. And is there anything you're particularly excited about with JSF 2.2, which is
supposed to be out sometime this year?
|Brian|| Yeah. I'm really excited with what's coming in JSF 2.2. Along with the bug fixes for certain
issues that I've been tracking that are key to me, the Seam Faces viewAction is going to be
part of JSF 2.2, which is quite exciting. And I'm also excited that CDI integration as a whole is
being looked at, with allowing CDI injection in JSF components, and other such integration
|Kito|| Yeah. That'll be really nice. I kind of felt like the JSF/CDI integration story wasn't quite done,
which was kind of a shame because that's what Seam was really doing very well with Seam
2.x. So, that's a good segue then.
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?
|Brian|| Okay. So, the viewAction component...you can think of it like listening to the pre-render view
event but on steroids. It provides a front controller for JSF applications. So, imagine if you
come to a JSF page from outside the framework, you haven't navigated to this page through
JSF, so it has nothing built up in its session to know where you came from or who you are or
what you're working on. You can use the viewAction to initialize the application on entry into
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.
|Kito|| Okay. So, it's implemented as a Facelet tag, it's not like the old pages.xml that was in Seam?
|Brian|| Right. That's been replaced by other features in Seam Faces. But that's not what the
viewAction component is addressing. The viewAction component is specifically an action you
want to execute when you first load the page.
|Kito|| Okay. And how is that...I guess the benefit, the reason it's better than the pre-render is
because it's before any real processing occurs with the page, right? Before the component tree
is created and all that kind of stuff.
|Brian||Well, it's much more flexible. With the viewAction component, you can specify which phase
you want it to execute at. So, it doesn't have to be before render. You can do it at the very
earliest instance, if you choose. If you want to just, say, look at this user ID, are they allowed to
access this? You can do that before the UI tree is even built-I'm sorry, before the component
tree's even built-to save the resources from having to do that.
|Kito|| Okay. Alright. That'll be really nice. I know people have been looking for that for a while now.
So, what other sort of key features do you like or would you like to discuss about Seam Faces?
|Brian|| So, we can talk about some smaller features, which I call the developer productivity
improvements. But first, let me back off a step, and just reiterate that what Seam Faces is
really addressing is bridging the JSF 2.0 and CDI technologies. So, it allows a JSF 2.0
developer to take full advantage of the CDI programming model in their application, without
having to deal with this impedance mismatch between them.
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.
|Brian||Another key feature of JSF-or I'm sorry, Seam Faces, is bridging the JSF events into the CDI
event mechanism. So, when we're in JSF land, if you will, and we want to write phase listeners
or system event listeners, we have to implement interfaces and define the methods that we
need to implement of that interface. Well, with Seam Faces present, those phase listener and
system events are propagated into the CDI event bus. So, we can write a phase listener or
system event listener as simply as writing the @Observes annotation from CDI.
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.
|Kito||Yeah. Nice. So, Seam Faces-is it on 3.1 right now?
|Brian|| Right. We've just released Seam 3.1, which includes a 3.1 level of all the included modules.
|Kito|| Right. And to be clear, there are lots of modules. Seam Faces is just one, but they can all be
used independently-well, for the most part. There are some dependencies, right?
|Brian||Well for the most part, the only dependency really comes on Seam Solder, the core library.
And then, all the other modules try to be independent-when they notice another module is
present, they'll enable certain behavior. Like, you can use Seam Faces independently, but if
Seam Security is present, you can use Seam Security control access to your views. So, it's ala
|Kito|| Right. Now, people who are familiar with MyFaces CODI, or with CDI extensions, may notice
that the Seam Faces functionality is pretty...it overlaps to a certain degree. And so, I think that
kind of brings us to a new Apache project called DeltaSpike, which includes a cooperation
between JBoss folks, the MyFaces folks, and some others on some common CDI extensions.
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?
|Brian|| Right. So, the goal of DeltaSpike is to create a set of de facto CDI extensions. This project is
being worked on collaboratively by the MyFaces CODI folks, JBoss, the people who've been on
Seam-there are a number of other contributors as well. I can't name them off the top of my
head, but if you go to the DeltaSpike page, you can find more information there.
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.
|Kito|| Okay. You can think of DeltaSpike sort of being like Seam 4.0, in some ways.
|Brian|| You might be able to make an analogy that way.
|Kito|| Yeah. I mean, obviously...
|Brian|| I'm just going to be careful there.
|Kito|| Well, I mean in terms of having...for those who are Seam 3.0 users, you know, if they're
wondering what's going to happen to their project, DeltaSpike is where they should look for
|Brian|| Right. We are going to keep Seam 3.1 going, we might have another micro-release there to
provide some bug fixes and improved documentation. People can continue to build their
applications there. And then there will be a migration to DeltaSpike once DeltaSpike becomes
ready for that. DeltaSpike is moving at what I consider to be an amazing pace. So, things are
looking good in that regard.
|Kito|| I'm very happy to see it too, because there's...I mean, I know there are more people than just
the MyFaces guys, but I know those guys pretty well, and they're pretty bright. So, it's really
nice to see you guys who are also quite bright as well, collaborate on this. I'm really kind of
excited to see what comes out of it.
|Brian|| Yeah. I think there's going to be nothing but good that comes from this collaboration, for sure.
|Kito|| Yeah. Definitely. Well, I think those are all the key questions I had for you. Is there anything
else you'd like to discuss or share with the audience, Brian?
|Brian|| No, that pretty much covers it. I just wanted to give...make sure people know about the
openness of the RichFaces project. If you're a RichFaces user, feel free to come and get
involved with us. Get involved through social media with Twitter or Google+. We're active
there. Come visit on us at IRC, or through our forums. Just get involved, let us know how
you're using the project, how you want to see it evolve.
|Kito|| Okay. Alright, Brian. Well, I thank you very much for your time. And hopefully, we'll get to
meet again at the JAX conference and the JSF summit sessions this year. That'll be nice to get
back to California.
|Brian|| It will be. Nice and warm.
|Kito|| Yeah. Alright. Take it easy. Thanks a lot for joining us. Appreciate it.
|Brian|| Okay. Thanks
|Announcer||That's it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann. Thank you for listening.