Editor's note: Soon after this podcast was recorded, we learned that IBM has recently begun planning a Portlet 3.0 spec.

 

Kito:

Hello and welcome to the JSFCentral podcast series.  My name is Kito Mann and I'm here today with Neil Griffin from Liferay who is here to talk to us today about Liferay Faces, which is a project which helps integrate JSF and portlets into Liferay.  Welcome, Neil.

Neil:

Hi, Kito.

Kito:

Good to talk to you again.  I think—when did I see you last?  Wasn't it like last year, I think?

Neil:

Yeah.  It's been a while, I think, since we saw each other.  I think we saw each other in Austria when we were at the conference out there.

Kito:

Yes.  At CONFESS. 

Neil:

Right.  But that was for CONFESS 2011, I didn't make it out there this year for 2012.

Kito:

Right.  It was very beautiful, I must say.

Neil:

Yeah.  I heard it was really nice up in the mountains.  I wish I was there.

Kito:

Yeah, oh well.  I think there were like fun things you could do because it was sort of a resort, but I didn't do any of that stuff, so I can't really speak to the sauna or the pool or the hiking or any of that stuff.

Neil:

Well, the year before it was in Vienna, but after the last day or so, I went to different parts of Austria.  And I took the Sound of Music tour and…

Kito:

Nice.

Neil:

Yeah.  They really don't know that movie so much, the Austrian people. 

Kito:

Oh, really?

Neil:

Yeah.  Because I talked to some of the people at the conference about it.  And Sound of Music is more of a—is much more popular in the U.S., of course.  But all the kids know all the songs, right here in the U.S., from that movie.

Kito:

Yeah.  That's one of the super always-popular movies.  I found out recently it's like a movie my parents watch every year.  And I didn't even know that growing up.  I didn't know what they were doing.

Neil:

Well, every once in a while in my house, we'll break out the puppet show scene on the DVD just to lift the spirits around here, if we're having a tough day.

Kito:

Yeah.  I can see that.

Neil:

The kids love it.

Kito:

Very cool.  Alright.

So, for those who don't know you, Neil, tell us a bit about yourself.

Neil:

I've been doing software development for about 20 years or so.  And just recently, I started with Liferay in January of 2012, this year.  Prior to that, I worked 15 years for a company, which is called Triton Services, which is a Liferay Platinum partner.  And prior to that, I worked for a contractor in the D.C. area.

So after that job I started working with Triton.  And they had acquired a product from Sybase, which was called Gain Momentum.  And Triton acquired it and all the customer base.  And I was the software lead for that.  And we renamed it to RadBuilder, we did some things like we made a Netscape plug-in for it.  We made the Active X control for it, so it would run inside of IE.

It was basically a—in some ways, it was a competitor to PowerBuilder and VB.  In other ways, it was a competitor to Java or JavaScript because it had a cross platform VM type of thing.  It was really way ahead of its time. 

But ultimately, the market went towards HTML based web apps, of course.  And so, that product came to the end of its lifecycle.

Then, I started working…let's see.  After that, I guess it was 2001-2002, and I started doing Java development.  And I started working with the portals first, actually.  There was a company—I don't know if you ever heard of this company, it's called SilverStream.

Kito:

Yeah. 

Neil:

They were based in New England.  They got acquired by Novell, but they had a great IDE that was based off NetBeans, they had a J2EE app server—you know, the whole stack.  And then, they had a portal product, but this was before the JCP had standardized portlets or anything.

Kito:

Right.

Neil:

And I remember being on phone calls with different portal vendors at the time, you know, asking them "I'm really concerned—are you going to implement the portal standard?"  And so, I was working with the SilverStream product, and actually, we ended up not using it on a project I was on.  We started to do just straight HTML, Java based servlet type of applications.

But then, in 2004, this thing called JSF came out. And I remember when it first came out, I absolutely fell in love with it.  And you might think this is funny, but it was actually because of the tooling perspective that it brought.

Kito:

Oh yeah.  No.  I totally understand that.  Definitely.

Neil:

There was this NetBeans variant from Sun, which was called Java Studio Creator.  Do you remember this?

Kito:

Yeah.  That was a great product.

Neil:

It was great.  It was led by Craig McClanahan, you know, after he had done the EG work, for JSO 127, he moved onto that.  And the reason why I liked it…I'm sorry, did you want to say something?

Kito:

I also was going to say a lot of the Java Posse guys used to work on that team.

Neil:

Yeah.  It was a great product.  And the reason why I liked it so much is it was really similar to what I had been doing with the Gain Momentum product.  Except it was based on Java, you know? 

And so, it was just a natural fit for what I was used to and what I was doing.  But ironically since then I think—I don't know if you would agree, but I think that the tooling part of JSF has become less and less of a driving factor in it.

Kito:

Oh yeah.  Definitely.  It's actually fascinated me because I thought—I was sort of like you.  I used to do Delphi development.  And so, I was all into the component aspect in the tooling.  And I was kind of surprised to see that it never really—you know, Java Studio Creator was kind of the coolest thing.  I think the only tool out there that really does anything that special these days is maybe JDeveloper with the Oracle components.

Neil:

Well, actually that got rolled into NetBeans itself, it was kind of like a NetBeans feature.  And then, the Woodstock components got end-of lifed and then, I think they recommended ICEfaces to their customers at the time.

And so anyway, I still think there's a place for tooling with JSF, but maybe not what the original vision was.  We still need it, code completion and things like that. 

So then after that, around 2004-2005, I was developing some plain JSF web apps for Triton.  And the intent was to make them commercial products.  But then, in early 2005 I was doing a competitive market analysis of these applications I was developing—what was out there and who we were going to be competing with.  And I've stumbled across this product called Liferay Portal.  And I downloaded it, I took a look at it, I was absolutely amazed at how much it provided out of the box.

And there's actually a little bit of overlap with what I had built, and I decided to get rid of the overlap, and that I would take the JSF web apps that I made and I would just make them be portlets and package them inside of Liferay as a value-add.  And it worked out really well.

In 2005, I don't know if you remember.  Actually, we talked about this once before, you probably remember.  In June, there was the 2005 Java 1.0 conference, and there was this presentation that Stan Silver gave.

Kito:

Yes.  I do remember that.

Neil:

And it was titled Building Killer Portlets with JSF.  And the room was absolutely packed, and it was standing room only, and it was just a great presentation.

Kito:

See, I couldn't get in.  I showed up too late and there was a line outside, and it was still too full. 

Neil:

Yeah.  It was really hard just to see Stan, or to see the screen—just to look over the people. 

But I fell in love with just using JSF inside of portlets.  I just thought it was a perfect match.  And it was just—it fit really well with what I had done in my career so far.  And then, I guess…in 2006 or so, we got JSF 1.2, and Facelets, and we were all kind of moving away from JSP to Facelets at the time.

Around 2007 is when I actually got in contact with the people at Liferay for the first time.  I met with Brian Chan who is the chief software architect of the portal product. 

I was out at a symposium in Boston and I was showing him some of the JSF stuff that I had done inside of Liferay.  And as a result of that, Triton and Liferay entered into a partnership.  And for about a year, I was doing work for—you know, kind of services related work for Liferay full-time as part of this partnership.  And after that, it kind of reverted to more of a traditional partnership where I was just working for Triton and doing Liferay deployments for customers.  Things like that.

But during that time, it was really neat how it worked out.  I was at the Orlando Airport, I was going to Java 1.0, I guess it was around 2007.  And you know how it is, you're looking for—in the airport, you're looking for power so you can charge up the battery…laptop?

Kito:

Yeah.

Neil:

And I checked this outlet and it didn't work, and the next outlet and it didn't work.  Finally, I sat down and I found one and there was these two guys in front of me who were talking kind of loud and I kind of overheard their conversation and they were talking about Java stuff.  I figured oh, well maybe they're going to the convention, to Java 1.0.  And I looked more closely and it was Ed Burns sitting there.  And I introduced myself.  I said excuse me, are you Ed Burns?  And he said yeah.  And I had recognized his face from his blog, you know?

And so, anyway, we became friends and soon after, he asked me to join the EG for JSF 2.0.  I guess it was JSR 314 at the time, right?

Kito:

Right.

Neil:

And so, during this time, I always felt a drive to do JSF inside Liferay portlets.  And at that time, I was doing some training with ICEfaces and things like that.  And I met this person who ran a company called Mimacom in Switzerland.  And I think you've met Micha before, right?

Kito:

Yeah.

Neil:

And he and I had a lot of things in common; a lot of synergy with what his company was doing, with what Triton was doing, and leading up to what eventually became the portletfaces.org website.  We basically decided—the two companies basically decided to sponsor the creation of a bridge and some related technologies for use within Liferay. 

And so, I guess that went on for a year or so and then, an opportunity came up for me to work with Liferay.  And Triton and Mimacom were happy to contribute all of this work to Liferay, and then Liferay formulized it into a product, which is called Liferay Faces.

And that's what I've been doing since January.

Kito:

Okay.  Alright.  So, that leads us perfectly to the next topic. 

So, tell us—there's this project called Liferay Faces, which used to be called PortletFaces, right?  So, tell us, sort of, what the specific parts of it are.

Neil:

Well, portletfaces.org was a website—it's actually still up, it has a lot of links that point you to Liferay.  And there were three projects there; one was called PortletFaces Bridge.  There was another one called AlloyFaces and a third called Liferay Faces.  And as we were coming up with new names for these projects when they moved over to liferay.com, we took a lot into consideration about naming and branding and so on. 

And we decided that the PortletFaces Bridge project would be called Liferay Faces Bridge.  AlloyFaces would be Liferay Faces Alloy, and Liferay Faces project became Liferay Faces Portal.

And basically, those three main projects moved over under an umbrella project, which is called Liferay Faces.  And the main goal is to support the JSF standard within portlets.  And those are the three main projects.

There's also a bunch of demos that are there: the common use cases that we find, you know, inter-portlet communication and so on.

Kito:

I have to commend you, Neil, for having all those demos.  So many projects don't really have very—you know, they may have one demo and that demo you probably have to get from GitHub or something, and there's no documentation for it.  But you actually have several different demos for several different use cases that are packaged that you can just download and try, which I really like.

Neil:

Yeah.  You could just drop them right into Liferay, and they deploy and you can just run them.  And really, the thinking behind that is on the forums, we would get questions all the time, well, how do I do this?  How do I do that?  And I would be creating these demos to try—and then, I would point people in the forums to the demos.  And that turned out to be really powerful because people could download something that worked.  And then, they could kind of run with that idea. 

And I still do that to this day.  Seems to work really well.

Kito:

Yeah.  So, tell us about each of those projects.  So, let's start with the Liferay Faces Bridge.  What exactly is it?

Neil:

Okay.  If you want to use JSF inside of a portal, then you typically would use that within a portlet.  And Liferay Portal implements the portlet standard from the JCP, 286 is the number, it's the portlet version 2.0 now.  And what a bridge does is it bridges the JSF lifecycle to the portlet lifecycle.  So that it's JSF—as the portlet lifecycle executes, it can then trigger the execution of the JSF lifecycle and make sure that the JSF render kit renders the markup to a portlet and so on.

So, that's kind of the basic purpose of a bridge.  But when it came to JSF 2.0, there were all kinds of new features and things like that, which we had to do a little bit of innovation to try and make it—in order to make it work successfully. 

And in the Java world we have the JCP, of course, which standardizes all these different technologies.  And there are two standards out there for how to develop a JSF portlet bridge.  And you're actually a member of both of those teams.  Isn't that right?

Kito:

Yeah. 

Neil:

301, 329.  But as you know, when you all were doing that work, it was based on JSF 1.2.

Kito:

Exactly.

Neil:

And so, there was this need out there to develop a JSF 2.0 type of bridge.  And with all of the new features that came with JSF 2.0, like I said, there's a lot of things that we had to take into consideration that were kind of above and beyond what the JSF 329 spec was defining.

And so, we recently announced that Liferay Faces Bridge has passed all of the certification testing, and has now become certified by Oracle, has been compliant with 329.

And what's interesting is since 329 is for JSF 1.2, we actually had to—but we were targeting JSF 2.0—we actually had to create a branch that would compile against the JSF 1.2 API.  And so, we actually support both now.  We support JSF 1.2 for legacy type applications that need to be brought over.  And we also support JSF 2.0.

But we had to do that in order to achieve certification.

Kito:

Well, congratulations on doing that.

Neil:

Thank you.  And I got to tell you, Mike Freedman who is the chairman of both of those expert groups has been such a wonderful mentor and friend through all of this.  I'm really impressed with just the depth and completeness there is, especially with the TCK.  You can tell that he and the other people in the expert group really put a lot of work in there to make sure that it was—that it really touched all of the requirements and tested them all.

Kito:

That's cool because I hear—I haven't heard too many good things about too many TCKs.

Neil:

No.  The TCK for 329 is unforgiving.  And I say that in the best light.  It revealed a lot of…just design changes that needed to be made, you know, in order to do things correctly.  You could write code that passes a test, and then you can write code that's correct.  And I have to say that that TCK forced—absolutely forced—me to make sure that all of the code was correctly implementing all the requirements.  And I was just amazed at how future complete it was.

Kito:

Now, I must admit, I remember during the spec process for those JSRs, I mean, every time Michael would write an email, it would be like so dense.  It's not one of the things you could just read quickly, you'd have to be like "okay, I need to actually read this and parse it now."  I was always very impressed with that depth of understanding that he had.

Neil:

He was the right man for the job because he really understood what needed to be accomplished.  And I'm just really grateful that he was the man leading those expert groups.

Kito:

Right.  Well, so this bridge supports JSF 2.0.  And it supports 1.2 and passes the TCK or technology compatibility kit for 1.2.  Now, for JSF 2.0 support inside of a portlet, there's no standard yet though, right?

Neil:

That's right.  There's no standard, and we're still trying to figure out how we want to do that moving forward.  You see, JSR 329, pretty much everything in there totally applies to a JSF 2.0 environment.  I guess the only main thing that I would add to that is that it doesn't address Facelets as a technology.  It's very JSP centric.  But adding Facelets as a primary technology for developing views is—it doesn't interfere or it doesn't really—it doesn't conflict in any way with 329.  It's just a natural fit, really.

Kito:

Let's move onto the other projects, and then we'll probably loop back around to JSF and portlets a little bit.

So, there's two other parts of Liferay Faces project, right?

Neil:

That's right. 

Kito:

So, what is Liferay Faces Alloy?

Neil:

Liferay Faces Alloy is part of this umbrella project called Liferay Faces.  And it's a JAR; it's just a dependency that a developer can add to a portlet project.  And it's meant to leverage Liferay's Alloy UI toolkit in a way that you would use it for JSF.  And for those who don't know, Alloy UI is a set of HTML and CSS and JavaScript technologies that are designed to be friendly, a portlet environment.  Because you can pick different JavaScript toolkits that don't play very nicely in a portlet environment.

And Liferay has a very challenging problem that the company has solved where we have a portal product that has to work in many different browsers.  And there are many different portlet technologies that you can choose, JSF being one of them.  Straight JSP portlets and lots of different JavaScript type libraries you can use. 

So, in order to solve this problem Liferay started with YUI 3.0.  And then, fortified YUI 3.0 with some CSS and some…to ensure some consistency with HTML that would work within portlets.  And that's called Alloy.  So, if you go to Liferay.com and you click on community, you'll see that there's an Alloy UI page there and you can read all about it.

And again, Liferay Faces Alloy is there in order to help JSF developers utilize this technology.

Kito:

Now, usually would a JSF developer think of Alloy UI as another set of JSF components they could use instead of PrimeFaces or ICEfaces?  Or is it something they would use with those component suites?

Neil:

Right now, it's the latter, meaning it's something that's complimentary to different component suites.  But the roadmap includes creating JSF components that will manifest these YUI widgets. 

So right now, it's meant to be complimentary.  And in the future, it will continue to be complimentary, but there will be some overlap as well.  There will be different types of pick lists and so on, where perhaps you'd want to use Liferay Faces Alloy 1.0 or maybe you'd want to use one from the other component suites.

So, again, right now it's largely complimentary, but in the future there'll be more components.

Kito:

So, if you—so let's say I have a portlet that I've written like PrimeFaces, for example.  Why would I use Alloy UI?

Neil:

Well primarily, right now, the reason why you would use it is to benefit from the CSS part of Alloy UI.  Alloy UI has some terrific features that are CSS related for making sure that forms line up nicely in different columns, with different labels of the field sets that make them look consistently like Liferay portlets. 

And actually, Alloy is not a portlet technology, it's something you can use in a web app.  And that's also true of Liferay Faces Alloy.  It's a JAR that doesn't have any dependencies on portlets at all.

Kito:

Oh, I didn't realize that.  Okay.                                                                           

Neil:

It's just…of course, since it's a Liferay technology, most people, I would assume, would use it within Liferay Portal.

Kito:

Okay.

Neil:

So primarily, to answer your question, the reason for using it right now is…for example, there's a component, which is <aui:fieldset>.  And that's something that helps forms line up correctly, and like I was describing before…it's mostly a CSS problem that is being solved right now by Liferay Faces Alloy.

Kito:

Alright.  So, there's one other part of the umbrella project, right?  Liferay Faces Portal.

Neil:

Right.  And hopefully people don't think that's a portal product.  It's meant to—what it is, is it's a JAR that developers can add as a dependency to their portlet projects.  And it's a bunch of Liferay specific utilities, and some JSF UI components and some Facelet composite components that are meant to be the JSF equivalent of functionality that ships with Liferay out of the box.

So, if you're going to use Liferay out of the box and you're going to use a straight, let's say, a JSP portlet.  There are a bunch of JSP tags; some begin with Liferay UI as a prefix, there's Liferay UI, Liferay Security, Liferay Util.  And in order to use these within Facelets, you need to have Facelet components that will make them work in a Facelets portlet.  And so, Liferay Faces Portal is primarily meant to be—bringing existing Liferay out of the box functionality to the JSF community.

Kito:

Okay.  So, if you were to look at like a typical developer that was building a Liferay portlet for Liferay from scratch, they probably would use all three of these, it sounds like.

Neil:

Yeah.  That's exactly right.  And I remember talking to Brian Chan when we were thinking about packaging.  And the project was built with Maven.  And he really made a big push to have kind of an uber project where you had this project called Liferay Faces and you had all of this stuff within one project, within one version number, that's really simplified—you know, deployment and keeping track of other versions and things.  Because Liferay Faces, this main uber project, has a version where the first…so, it's got a major.minor.release type of versioning. I've written a blog about this.

The major version has to do with which version of the bridge and which version of JSF we're talking about.  And the minor version has to do with what version of Liferay Portal we're trying to target.  So, there's a version of Liferay Faces for Liferay 6.1, and Liferay 6.0, and the master branch right now is targeting Liferay 6.2, which is coming next year.

So, there are parts of the project which have Liferay kind of dependencies and other parts do not.  But this versioning helps us keep track of what version of Liferay Portal developers are targeting.

Kito:

Right.  So, that brings me to another question.  So, let's say I was writing a portlet and I wanted it to work in Liferay, but I also wanted it to work in GateIn, which is the JBoss portal or something.  Could I use Liferay Portlet Bridge part, and use it in GateIn and have it magically work?

Neil:

Yeah.  I think it will probably work.  I mean, we're focused on Liferay Portal, of course.  There is some testing that's done in Pluto just to make sure that the bridge is doing things within the confines of the portlet API.

Kito:

And then Pluto is the portlet sort of—I guess you could call it a reference implementation, but it's not really a portal server, it's like the portlet container reference implementation.

Neil:

That's precisely what it is.  Yeah.  It's the reference implementation and it's at Apache.  And so, we do testing inside of Pluto, but also in many different versions of Liferay Portal.  And the testing that we do is really quite extensive because there's Liferay 6.0, 6.1, and of course, 6.2.  There's the community edition of Liferay Portal, plus the enterprise edition of Liferay Portal.  And all of the regression tests have to be run in each one of these scenarios to make sure that we can support customers for lots of different versions.

What's funny is when you look at a normal portal—I'm sorry, a  normal software project, and you start with version 1.0 and then 1.1 and then 1.2, and maybe you have some major new thing that justifies having a new major version, you have version 2.0 and then version 3.0 and so on. 

Well, with Liferay Faces we basically came out with version 3.1 and 3.0, which have equivalent functionality.  So, they're both brand new.  And it's not like version 3.1 has more functionality than version 3.0. 

So, as we move forward with new releases, you know, with version 3.1.1, there will be an equivalent to 3.0.1 that has all the back ports.  And so, really the new versioning that you'll see with Liferay Faces is in that dot release.

Kito:

And you see that with the JSF implementation releases as well.  There's like MyFaces 2.0.x and then 2.1.x and I think Mojarra, the reference implementation does the same thing.  And each new version is 2.0.whatever, or 2.1.whatever, and essentially the same code base.  With whatever changes are specific for the 2.1 spec version.

Neil:

That's right.  That's right.  And so, that's kind of the approach we've taken with Liferay Faces because we want to provide—you know, Liferay Portal is in such wide distribution and I would have to imagine that most of the deployments that are out there are now at version 6.0 or 6.1.  There's probably a big footprint for Liferay 5.2 as well.

Kito:

I would imagine so.  Because it's a pretty big upgrade task.

Neil:

Yeah.  But one of the benefits of Liferay Portal is a lot of the upgrade path is automated.  Not all of it, I mean, I've been through a lot of the upgrades where there's some other things you have to do.  But upgrading the database is automated to a large degree.  And so, one of the benefits of Liferay Portal is customers can start with version 6.0 and move to 6.1.  It's not effortless, but from what I understand, it's a lot easier than a lot of other products.

Kito:

Yeah.  That's a good point.

Neil:

So, we're trying to provide Liferay Faces to all of these deployments that are out there with Liferay Portal.

Kito:

So, what do you guys use for testing all the different versions of Liferay with Liferay Faces?

Neil:

Well, believe it or not, the main driver of the testing is the TCK.  The TCK is so—now, that's just exercising the bridge, of course.  But that—the TCK has to pass inside of Liferay 5.2 in the enterprise edition, it has to pass inside of Liferay 6.0, Liferay 6.1, the community edition, enterprise edition also in Pluto.  And that has been a tremendous help just the TCK itself, making sure that all the tests pass in all those different environments.  Plus, there's different application servers that have to be tested.

Kito:

Right.

Neil:

JBoss and GlassFish and Tomcat and—because Liferay has this really great approach of…you can use Liferay portal in all of these different application servers and servlet containers, in all of these different databases—and it's great because it really lowers the barrier to adoption.  Who's going to use the product?

So, to answer your question further about testing, you know what has really helped with testing is all of the demo portlets that we were talking about before.

The demo portlets are not just showing people in the forums how to use features this and that.  They're meant to be kind of—not just simple use cases but comprehensive use cases.  So, let's take—there's a demo there, which is just called the JSF 2.0 portlet.  And it's a simple form where you're filling in kind of a job application, but it's doing all kinds of stuff.  It's doing—it's testing f:ajax, right?  For JSF 2.0 XMLHpptRequest.  It's testing converters, it's testing required validation, it's testing conditional rendering within the browser; it's testing navigation, right?  Using Ajax from one view to another, it's testing the flash scope.  It's testing all different kinds of things…file upload. 

So, it's kind of—it's not just a standard use case for one component, it's more the typical use case that exercises all kinds of functionality within JSF, within different component suites.  We've got one for—there's an equivalent for ICEfaces, for PrimeFaces, for RichFaces.  And then, we have different forms of inter-portlet communication, like Portlet 2.0 public render parameters, a different one for events.  We have one for ICEfaces, for inter-portlet communication using Ajax Push.

And all of these demos put together form a tremendous test suite to make sure that in these real world application scenarios that all of these features are working in different versions of Liferay Portal.

Kito:

Yeah.  That's nice.  I kind of suspected that by looking at your examples that you also use them for testing stuff, too, which makes a lot of sense.

Neil:

Yeah.  It's really helpful.  And automating it with Selenium is typically what Liferay's all about, —this big push to have automated tests.

Kito:

Right.  Makes a lot of sense.

So, this sounds like a lot of work going on here.  I noticed there's a couple other people on the project list from—what was it?  Mimacom?  And Triton?

Neil:

Yeah.  Right.  From Triton, we have Atul Patel, he's the director there at Triton.  And he's made some very good contributions to the bridge.  And he and I have been friends for a really long time.  And so, I'm in contact with him about different issues.  Also, Robin Wyss at Mimacom.  And he's a specialist there with JSF and portlets.  And so, both of these gentlemen helped me with moving the bridge forward, because both of these companies had a tremendous amount of effort that they put into it to try and get these technologies kicked off.  Like I said, we're trying to fill a technology void.

Kito:

Right.

Neil:

And so, they want to see these move forward.

Kito:

So, did Brian give you a team of people at Liferay to work on this?

Neil:

Well, I'm the primary guy who works on it, but also, when you make a product—I forgot to mention, Liferay Faces is…support for Liferay Faces is offered for anybody who has an enterprise subscription to Liferay EE product.  And so now, the entire support staff at Liferay is ready to field questions or to field these issues that customers have if they're having trouble with Liferay Faces or if there's some type of compatibility issue that they're trying to work through.

And so, there's the entire support staff at Liferay who stands ready to help.  And there's—you know, Liferay has really grown as a company.  There's several hundred employees now, on many different continents.  And really, we have people all over the world who are involved with Liferay Portal.  And it's not just a one product company; there's another product, which is Liferay Social Office.  And now, a lot of these side projects that compliment the larger projects, Liferay Faces being one of them, they all have to be supported.

And there are different…there's also a consulting arm at Liferay that is there ready to help me as well.

So, there's quite an extensive team.  Everybody has their different area of expertise in order to help this project move forward.

Kito:

Yeah.  That sounds pretty cool.

Neil:

I also wanted to mention there's the Liferay training and documentation department where we're going to have a training offering for this as well.  So, all of those resources there are ready to help me as well.

Kito:

It's so amazing just to see how far the company's come because like you, I started just sort of looking at it much earlier.  I think around Liferay 3.0—was that when I saw it?  And I remember talking to one of the Brians about how they need a book about Liferay.  And the documentation at that time was really bad.  Better than some projects, but it needed work because they hadn't hired anyone to do documentation yet.  So, just to hear you say the documentation and training department—

Neil:

Oh yeah, it's not just one guy part time...

Kito:

I know.  It's really…

Neil:

Yeah.  There's a department now that is there in order to improve and augment and develop new documentation and training.  And my friend Rich Sevoz has authored Liferay in Action, and he spent well over a year authoring this book and taking contributions from different people at Liferay.

Kito:

I was actually one of the reviewers on that, it's a really good book.

Neil:

Yeah.  Yeah.  It's a great book.  And there are a lot of different course offerings from Liferay as well.  Liferay also has a full-time person whose job is to do Javadocs. 

Kito:

Really?

Neil:

Yeah.  A full-time person just to do Javadocs and to make sure that all the Javadocs are consistent that software engineers would be adding to the product.  If Brian Chan is anything, he's all about consistency.  He wants consistency throughout the product, and that includes the Javadocs and the documentation.  So yeah, there's a lot of effort at Liferay to make sure that Javadoc and inline Java comments are consistent.

Kito:

That's really cool because I remember looking at the code in some of the earlier days and there were like no comments anywhere.

Neil:

Yeah.  Well, that probably comes from the genesis of open source, right?  Where you start out and it's a couple of guys who have this great product idea and they put it out there in open source.  And then, there's a lot of momentum behind it and is a growing company.  And one of the things that customers need, that developers in particular need is great documentation.

So, there's a big push at Liferay, a lot of resources that are targeted towards getting a documentation where it needs to be.

Kito:

Well, it's definitely made a big difference.  I mean, I've noticed now—because we're using…(full disclosure, we're using Liferay for the next version of JSFCentral).  It's just so much easier to find stuff now; the current level of just the free documentation is quite good.

Neil:

Yeah.  There's…if you click on documentation at Liferay.com, there's a user guide, there's a developer guide, and they're really comprehensive in many ways.  So, really great documentation.

The community is out there helping with Wiki articles and things like that, but the documentation that's available from Liferay is really quite good now.

Kito:

Yeah.  Alright.  Before we wrap up here, just a couple more questions.

So, this is a sort of fun thing.  What, Neil, is your favorite thing about JSF?

Neil:

My favorite thing about JSF…you know, you may laugh, but my favorite thing I think is the lifecycle. 

Kito:

Oh, fascinating.

Neil:

I've taught many training classes about JSF and you put that big scary JSF lifecycle diagram on the screen, and the students start to shrink in their chairs.  And my first thing that I try and teach them is: fear not, this is your friend.  And I like it.  I like the JSF lifecycle.  There's some intricacies about it that—you know, at first, it's a little tough to get the grasp of, but there are a lot of things to love about JSF.  There are naysayers, of course, about JSF.  But there are a lot of things to like about it. 

And the lifecycle is one of the things that I really like.  Because I think once developers understand it, and they can appreciate it and it's really one of the best friends.

Kito:

It's certainly quite flexible.  That's one of the key things, I think.

Neil:

And really, another thing that I like about JSF is…JSF's been around a long time.  It's getting to be about—in some ways, it's over ten years old.  I mean, the initial idea is what…2001, 2002?  And just as you see over time how JSF has matured, you know, with the additional Facelets, and really the JSF 2.0 coming out was a really big deal, as you know.  And there's the standardization of how we do Ajax or all the different component suites. 

There are a lot of technologies where they're the hot thing for a few years.  And then, there's the next hot thing and it kind of goes and withers away.  But JSF has really been able to compete and stay relevant for a long time now.  And so, I think that's a testimony to a lot of the ideas that were in there originally.

Kito:

Yeah.  Even I will not say it's perfect, by any means, but yeah.  I look at sort of how things have progressed over the years and there's still plenty of market demand for it.  So, to me, that says a lot.  Just to know that there's plenty of people still doing JSF projects, starting new projects, et cetera, after all this time.

Neil:

Yeah.  And the component suites have really…offered a lot of value-add.  I mean, there's a really big component case to use JSF.

Kito:

Yeah.  So, that does bring me to my next question—well, actually it doesn't bring me to it.  So, what's your least favorite thing?

Neil:

My least favorite thing is the thing that everybody has run into where…unless you have…during development, unless you have some type of a face listener that's showing you the execution of the lifecycle, you know, in different phases, you're going to run into problems that will frustrate you to no end.  So for example, you're developing—just a simple example—you're developing a form and you have some type of validation on the form.  And you're trying to click on a button and you click on the button and you click on the button and nothing's happening.

And it's because the lifecycle is short circuiting or something at the process validations phase and you're wondering well, why isn't my listener getting called?  And so, I think that's my least favorite thing is—whereas the lifecycle is your best friend, it can also be your worst enemy if you don't understand just these little development tricks that you need to be using with the JSF.

Kito:

Well, what do you think…JSF 2.2 is currently in development and we're both on the expert group, right?

Neil:

Uh-huh.

Kito:

I know one of the things that you've lobbied for heavily and I've lobbied for it to some extent is better support for portlets.  And that's not just necessarily with JSF but more with CDI context and dependency injection in Java.  Do you want to talk about that for a minute?

Neil:

Yeah.  Well, I guess there are two different questions.  I'll take the first one first, about JSF and portlets. 

So, from the beginning there was an effort to try and make JSF not be a servlet API dependent type of technology so that it could be used in either a servlet environment or in a portlet environment, or even in other environments.  And over the years, what had happened is in the reference implementation in Mojarra and also in MyFaces, you'll end up with…accidentally developers will put in casts to HttpServletRequest, where it might cause problems and so on.

And so, those are bugs that we work out with the maintainer and the developers of Mojarra and MyFaces.  But occasionally, there are some API challenges.  And so, I think one thing that Mike Freedman had requested was to have an external context factory added to JSF 2.0.

And that really cleaned things up a lot from the creation of a JSF portlet bridge from that perspective.  So sometimes, there's things in the JSF API that have to be added in order to accommodate portlets in a little bit cleaner way.

So, one of the things we're doing in JSF 2.2 is to try and make sure that portlets are really a first class citizen for JSF developers.  And there's some things that we've asked for with JSF 2.2 that the expert group has been agreeable with, that are going to be in there.  Some of them are just the addition of some wrappers that need to be in there, some accommodation with renderers and so on.  Just to make sure that portlets are always a first class citizen.

So, that's the first question.

The other question is about CDI.  Portlets are a server side Java technology, but they are not part of Java EE.  And so, every once in a while we run into a situation where you have a Java EE technology, like JSF.  And there's a big effort made to make sure that it works with portlets and you end up with JCP standards for portlet bridges and so on. 

And then, you have other technologies like CDI, and we have—I think there's two implementations, right?  There's Weld and then OpenWebBeans… 

Kito:

Yeah.

Neil:

…are the two.  This technology, CDI is so powerful and people want to use it in portlets, but CDI version 1.0 did not have any language in this spec for portlets.  And right now, CDI 1.1 is being developed.  And there may or may not be language in there about portlets.

Anyway, like I said, CDI is a Java EE technology, and we're trying to move forward with making sure that it works well with portlets.

Kito:

Well, and just to add to that, I mean, part of the conflict here is that JSF has managed beans, which most people would like to replace with just CDI.  And you'll find plenty of developers that wouldn't even start a JSF project without using CDI.

Neil:

Correct.

Kito:

But we can't really get rid of managed beans and say use CDI if the CDI doesn't work well in portlets.

Neil:

Right.  I mean, you can make the argument that portlets are not a Java EE technology.  But in reality out there in the marketplace, there's a lot of people who develop portlets—and use a lot of other Java EE technologies where they need it to work together.

So yeah, I've seen guys in the Liferay forums who are making posts saying how come we can't use CDI?  It's like chocolate and peanut butter.  And they're missing one or the other.

And it's not just the dependency injection, they want to use a lot of the other features that are in CDI, the interceptors and so on.  And so, it's really important; Liferay has committed to making sure that we're trying to help move this forward.  Because it's important to our developers and our customers. 

Kito:

Yeah.  Definitely.  Alright.  So, I guess the last question is: if you were to look sort of at the future, say the next two, three, four years.  What would you like to see in terms of the portlet spec and the JSF spec?

Neil:

Well, with the portlet spec, I'm not aware that there are any plans to form an expert group for Portlet 3.0.  Traditionally, that's been chaired by IBM.  And I've done some searching out there to see if there are any plans.  I haven't—I'm not aware of any plans.  Doesn't mean there aren't any.  But as far as I know, it's not being revved right now.

When you look at the Portlet 2.0 API and what portlets are and what they were intended to be, portlets in general…certainly this is true of Portlet 1.0. They were a very web 1.0 type of design, in that there's a lot of faux post-back type of use cases, where the page would have to re-render and the other portlets would have to re-render themselves, and so on.

Portlet 2.0 introduced support for Ajax using this new part of the portlet lifecycle, which is called the resource phase.  And Liferay Faces Bridge takes advantage of that when doing Ajax and things like that.

So, Portlet 2.0 has become much more Web 2.0 friendly.  But still there are things that could be done to the portlet API in order to accommodate a much more rich experience.

But even though that hasn't been standardized, there's lots of different ways to achieve that just with the products that are available.  I think of the different Ajax Push technologies that are out there in order to create a rich UI for use within portlets.  We've done a lot of work with the ICEfaces Ajax Push feature, and making sure that that works for inter-portlet communication. So, I guess the future of portlets, I would like to see another expert group form. 

Future of JSF?  I think there's still a lot of innovation that's being done with JSF.  You know what I see happening is…JSF is JavaServer Faces, of course, right?  And the initial idea was that the server was going to be doing a lot of work because the browsers back then were really slow at executing JavaScript and doing things within the browser client itself.  But in recent years, we've seen these great JavaScript libraries at JQuery, JQuery UI, and Alloy, of course, which leverages YUI. 

And so, you see the browser doing more and more and more work of rendering these beautiful user interfaces.  And being much more heavily dependent on the speed of the JavaScript engine that's part of the browser.

And so, that's another testimony to JSF; even though it was JavaServer Faces, we've been able to use this server side technology to manifest HTML markup and complimentary JavaScript in order to leverage the power of the browser.  And it's still very relevant. And so, I see that happening even more so, as the browsers get faster and faster, and we're going to see more and more demand on the JavaScript component of this.

Also, life is changing with regard to mobile, and with regard to the different devices that we use, whether it's an iPad or an Android phone or whatever it might be.  And we have all these different displays that we need to target.  And we also have the beauty of the hybrid app for these mobile devices.  We have—you'll have basically an app that leverages WebKit or some type of other type of browser technology in the phone or the mobile device.  And so, it looks like a native app, it feels like a native app, but really, it's executing a web app, right?  Or invoking some web services or something like that.

And there's a place for JSF there, too.  And so, I think that's where we see the future there…in mobile, and how do we ensure that JSF the standard, and portlets the standard, play nicely inside of these mobile devices.

Kito:

Okay.  Alright.  Well, Neil, thank you so much for joining me.  It's been a great conversation.

Neil:

Sure.  Thanks for having me.

Kito:

Is there anything else you'd like to add?

Neil:

I don't know. Maybe have everybody visit Liferay.com and try out Liferay Faces.

Kito:

That's what I was going to say.  So, if they just go to the site and then click on Projects, it's listed, right?

Neil:

Actually, you click on Community and there are projects, which are community projects hosted by Liferay, sponsored by Liferay, one of which is Liferay Faces.  Then there are other community web projects.  So, click on Community and you'll find it there.

Kito:

Alright.  Well, thanks again.  And hopefully, I will see you someday soon.  At some conference somewhere.

Neil:

Okay.  Look forward to it.

Kito:

Alright.  Thanks.

Neil:

Okay.  Bye-bye.

Kito:

Bye-bye.