JSF Central - Neil Griffin discusses Liferay and ICEfaces
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Neil Griffin discusses Liferay and ICEfaces
by Kito D. Mann
05 May 2009 02:30 EDT

In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Neil Griffin about Liferay, Ajax, and ICEfaces. This was recorded in September of 2008 at JSFOne.


Podcast (MP3)
Welcome to the JSFCentral podcast #13 for the week of April 27th, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology. Neil represents Liferay on the JSR 314 JSF 2.0 expert group.
Kito Hello. My name is Kito Mann. I am here at JSFOne 2008, day #2, in Vienna, VA right outside of Washington DC. I am here with Neil Griffin who works at Liferay. We are going to chat a bit about Liferay and Ajax and ICEfaces. Just to begin with, Neil, how is the conference going for you? I'm pretty tired myself.
Neil It’s late, because the conference goes late and then there are BOFs and things like that.
Kito Yes.
Neil Lots of people to talk to, but it's fun. A little low on sleep but it's fun.
Kito Alright that's good. So you work at Liferay, right? So tell us a little bit about what you do, where you are focusing, and what your background is.
Neil My background is in J2EE, just like everybody here. Actually, the way I came to work for Liferay was, I was part of the community and I was also part of the ICEfaces community, and when ICEfaces first came out it was a commercial off the shelf product. They had a community edition but it wasn't open and it didn't work inside of portals. Then, when it became an open-source product I got very excited and I was a member of both communities so I got the source and I tried making ICEfaces work inside of Liferay. ICEsoft had done some preliminary work and there were different JSF portlet bridges that I was trying, and I was trying the Sun Bridge, the Apache Bridge, and I had some moderate success making it work. I submitted my patches to ICEsoft, so I got on their radar screen. I was already on the radar screen of Liferay, so Liferay asked me to join and I became the technical point of contact at Liferay for ICEsoft. So I have got all the Liferay guys on IM and I have got ICEsoft engineers on IM and I serve as... creating demo portlets with ICEfaces and making sure that the quality is high and that they work inside of Liferay.
Kito Okay, so tell me a little bit about what you were doing before you were at Liferay.
Neil Before that I was using Liferay Portal and JSF - actually I have to tell you about Stan Silvert. It was back at Java One 2005, I had been using JSF for about a year and Stan Silvert had a talk - I don't know if you remember this - It was called Building Killer Portlets with JSF.
Kito I remember that was packed, I couldn't get in.
Neil Yeah, it was packed. It was over in the Yerba [Buena] Center and it was standing room only. I serve on the JSF 2.0 committee for Liferay, and at JBoss World recently I had the privilege of meeting Stan and I just met him again here at this conference and I thanked him. I said "really you helped define my career path with that very presentation you gave, because I needed to do portals in the job I was doing and I wanted to use JSF as a technology."

That kind of set me on that career path right there. I was using Liferay and JSF after that, and I was building portlets that helped the company with managing employees, human resources, timesheets. I always wanted to do expense reports, never got that far. I was doing a lot of heavy JavaScript to try and make some of these things rich. The amount of JavaScript I had to write in order to add a new row to a timesheet or something like that, it was just alarming and it was too much to maintain. Half of it was JavaScript, half of it was JSF, and then ICEfaces kind of came to the rescue.

Kito Okay, interesting. So we talked a little bit about Liferay and ICEfaces. Why don't you tell us exactly what Liferay is?
Neil Liferay is a portal server. Some people like to call portals, portal servers. I like to call them portlet containers. What it does is it implements the JSR 168 spec, which is portlet 1.0, and it also now implements JSR 286, which is portlet 2.0. What you can do is you can write portlets, which are rectangular regions of content. You can aggregate them on a page. The theory behind portals is that you can take different portlets and aggregate them to create a composite application.
Kito Okay, so how does this compare to... let's say I built a web application and I just wanted to have some regions and I just put some IFRAME on the page or something.
Neil A lot of people actually try to implement portals like that, where they will have different regions that are just IFRAMEs pointing elsewhere. There are a couple of different answers to that question. First of all, the one benefit that the portal provides is that it often has a single sign on or type of authentication engine that manages users and things like that. Oftentimes it comes with a lot of portlets out of the box. A lot of times people will build their own home grown portals with IFRAMEs. Each IFRAME is simply just displaying a news article or something like that. So portals like Liferay will have a portlet that enables content management. You can define your content in a "what you see is what you get" environment right there in the portal. Then once you have placed that content in the CMS you can drag and drop the rendered content, these portlets, anywhere on the page and build a whole website without using a tool like Dreamweaver.
Kito Okay. I think one of the other benefits too, in addition to the single sign on, is the access control right?
Neil Yes, the portlet spec defines this thing called a role. The role doesn't have a lot of meaning, it is just a name. So you can do a lot with that, but if you want to go fine grained then you would have to have a role named like "manager" and "manager of this department" and "manager of that department" and so on and so forth. You have to have many many role names to become fine grained. What Liferay Portal does, is it takes JSR 168, the role name, and fills it with more meaning, so a role is a collection of permissions. A permission in the Liferay understanding is a resource and an action. Let's say I have a portlet and it is a portlet like "users." What I can do is, maybe I can "add users," "edit users," "delete users," but that is if I was the administrator of the portal. If I am just Joe User of the portal then I can just "view users". The resource would be a portlet and the action would be edit, add, view, delete. So Liferay fills the portlet standard with its own meaning, which is very helpful.
Kito Okay, so Liferay is working with Sun on a portal server, right?
Neil That’s right. What happened is Sun had their own portal product and the team of engineers at Sun was looking at Liferay Portal, and decided that for the future they are going to create this new product called Web Synergy. They were going to take a Liferay Portal source and also contribute a lot of Sun technology to it and have a Sun offering of Liferay Portal and that is called Web Synergy. That is a recent announcement. I think it happened at Java One back in May.
Kito So there are still going to be separate products, like you can get Liferay by itself but if you want you can get Web Synergy, is that the deal?
Neil Right and Web Synergy will take a very stable version of Liferay Portal and then Sun will offer services on top of that, that will enable them to provide very top notch support.
Kito Okay, interesting. Alright so we talked about how there are these portlets which are these little regions or mini applications run in a portal server or portlet container.
Neil Right.
Kito So in general, those little applications you can write with any web framework that works with portal servers right?
Neil That's right.
Kito Or portlets?
Neil Well the strictest definition of a portlet is one that is written in Java. The portlet spec defines this thing called GenericPortlet that you have to subclass. Technically the only thing you can do is write to the response and that is how you manifest your HTML markup. No one really wants to do that. They want to do some type of MVC framework to do their portlets. You can do portlets in Struts, in Tapestry, and of course in JSF, which is my favorite way of doing portlets.
Kito Right.
Neil Liferay also supports portlets that are built in PHP.
Kito That is interesting.
Neil And Ruby, not Ruby on Rails portlets but you can use the Ruby scripting language to manifest your results in your portlet and things like that. Some people do portlets entirely with JavaScript technologies like JQuery.
Kito Interesting.
Neil Yeah, and Expandos and things like that in order to show results in HTML.
Kito Okay so in terms of JSF, talk a little about writing a JSF portlet.
Neil JSF portlet is a JSF web app, only a little more so. What you do is... Technically if you have a JSF web app that obeys all the rules of JSF and you are not doing anything funny, you can just add a descriptor called portlet.xml and slide that into the servlet container or the application server - let's say Tomcat - and deploy it, and your JSF web app will run as a portlet. Now on top of portlet.xml there are some jars that you need. The one really important one would be the portlet bridge. There are a lot of bridges you can choose from if you are doing standard JSF. The one that I use most of the time is the bridge from Sun. It’s the Sun OpenPortal JSF Portlet Bridge, that I think falls under the Glassfish umbrella of projects. There is also the MyFacesGenericPortlet, which Stan Silvert wrote for the MyFaces reference implementation. There is the Apache Portals Bridges bridge and of course there is the JSR301 bridge. I just came from a talk that Scott O'Bryan did - he does the reference implementation for Apache for that.
Kito So tell us a little more about what the JSR301 bridge really is.
Neil The nice thing about the JCP, the Java Community Process, is that a lot of times - and this is happening with JSF 2.0 as well - is there will be a lot of innovation done in a lot of these open-source projects, and even commercial projects, and the standard will be able to harvest all the great ideas, the best of breed from all these different projects, and aggregate them into a standard API, and then of course we can create a reference implementation and different implementations that offer more features on top of that. So with regard to JSR 301, Mike Freedman from Oracle is the chair on that and he also holds a seat on JSF 2.0. What they have done is taken the Sun bridge, the MyFaces bridge that Stan did, the Apache bridge, and also a bridge that Oracle has, and they have taken the best of breed ideas from those different bridges and they are coming up with a standard. They have a very challenging problem. They have to create two specs; one that works with portlet 1.0 and one that works with portlet 2.0. Each one has to support JSF 1.0 and JSF 2.0. So it's a very hard problem for those guys to solve - they are doing a great job.
Kito Yeah and I just want to point out that I am on that JSR. I am not nearly as involved as Stan or Scott but I have been pretty happy with the work that they have done. I think it will really make life easier for people trying to use JSF with portlets because often what happens is some bridges work well with some portals and not others. They all have their own little quirks and all these sorts of things. The reference implementation, I think is a pretty good piece of code too. I think it is still in alpha.
Neil Right, and also JBoss has an implementation that they have done for Seam and for RichFfaces. ICEsoft holds a seat on JSR301. We were talking earlier about how do you make a portlet work with JSF and of course you need a bridge. ICEsoft has a bridge as well in order to make ICEfaces work inside of a portlet container. Originally they were looking at using one of the existing bridges that was there, and because of the unique nature of ICEfaces and the Direct-to-DOM rendering technology-sometimes it is referred to as DOMdiffing-they thought it best to create their own bridge. I have contributed a little bit to that-mostly in a quality assurance.
Kito Okay, and if anyone wants to get a better handle on ICEfaces, there is a previous podcast on JSFCentral with Ted Goddard where we talk in-depth about ICEfaces. So if we say anything that you find a little bit confusing you should definitely check out the old podcast. In terms of ICEfaces you are pretty involved in making ICEfaces kind of a first class citizen in terms of Ajax interoperability on Liferay, right?
Neil Right, I think-and this is my personal opinion-but I think that ICEfaces is a perfect match for portlets because when you think about a portal, you may have multiple portlets on a page. Only one of them can participate in form submission. If I have four portlets, A,B,C and D, and I click on a submit button on A, what happens is the form submission happens on A but portlets B, C, and D-they didn't do anything wrong, but they are forced to re-render themselves and try to maintain their state. This very disruptive user experience happens where the whole portal page is re-drawn. Where ICEfaces comes to the rescue is-because of the Direct-to-DOM rendering engine in the ICEfaces product - you can interact with one portlet that is built with ICEfaces and it doesn't disturb any of the other portlets on the page.
Kito So explain that a little more. Give us a sense of why you would want inter-portlet communication, like a scenario that works, and what's different about it with pure JSF versus ICEfaces.
Neil I will just describe the demo I am going to give.
KitoOkay.
Neil I will describe it verbally. There are three portlets on a page. Two of them are JSF and one of them is just a JSP portlet that does a little JavaScript. The first JSF portlet is a list of customers; the second is a list of bookings. This is kind of a travel agent type of example where the travel agent is using the portal and would select a customer by clicking on a button like edit or something like that. When the customer is selected, using standard JSF, the whole portal page refreshes and the details of all the vacation plans of that customer show up in the other JSF portlet. Meanwhile, the JSP portlet, which happens to be a loan calculator, if I had been working in there and I wanted to plan a mortgage for 30 years or 15 years, that portlet completely loses its context and has to start over again. That's what the JSF example looks like. The ICEfaces version of that is the same exact layout, except when I select a customer it uses ICEfaces Ajax Push, which is commonly referred to as COMET or reverse Ajax. So when I select a customer, the Ajax Push mechanism will update the rendered content in the other ICEfaces portlet on the same page without disturbing any of the other portlets on a page.
Kito Okay, cool. So it sounds wonderful, but it sounds like it might have been difficult to make that work. Tell us a little bit about the challenges that you saw in terms of ensuring that Ajax works well in a portal server on top of JSF.
Neil ICEfaces is unique in that respect where... OK, we think about the JSF lifecycle. When we do HTTP GET, the only two phases of the lifecycle that are going to execute is the Restore View phase and the Render Response phase. That is a standard type of thing. So with an ICEfaces portlet that is what happens. Your view is constructed and rendered to the browser. That is pretty much the same as normal JSF. Every single thing that takes place after that does not go through the portlet lifecycle, it goes through the ICEfaces servlet. They have a bridge to enable partial submit, which is a layer of abstraction over XmlHttpRequest. So when I interact with the ICEfaces portlet, everything is going through the ICEfaces servlet, and the content that changes inside the browser is happening over the Ajax bridge using the Direct-to-DOM rendering technology.
Kito Okay, so how does all of this work in terms of JavaScript resources?
Neil In what way? Could you clarify?
Kito Well, Presumably, ICEfaces needs to load some JavaScript.
Neil Right.
Kito And there are several different portlets so they don't all want to reload the same JavaScript.
Neil Right.
Kito Who knows, if there is another portlet that is separate it might have some JavaScript and some libraries it has to load as well.
Neil Right.
Kito So how does all that work together?
Neil One of the nice things about Liferay Portal is it allows you to specify which JavaScript resources that you are going to need in each portlet. You can do it in such a way that the JavaScript will only get loaded once per page. In the case of ICEfaces what happens is, there's... for lack of a better name let's call it ICEfaces.js, that needs to be loaded on that first HTTP GET in order for the ICEfaces magic to happen. If I have multiple ICEfaces portlets on a page, that resource is already there and ICEfaces knows that and there is no conflict.
Kito Okay, nice. So one of the things about standard ICEfaces web applications is that they sometimes maintain this persistent connection, so that sometimes if you leave the page for a while and come back, and you refresh it, then it says "the connection had been lost, why don't you refresh your page." How does that work in a portal environment?
Neil It is very much the same. What ICEfaces is doing, from the initial time that the page is loaded throughout the lifecycle of the application, is measuring the health of the persistent HTTP connection that it holds open between the browser and the server, and that's what makes the Ajax Push magic happen. So there are things that can cause that connection to go down. The most obvious would be some type of disruption in the network, or I pull out my wireless card or something like that. Or my ISP has a failure. When that would happen, the ICEfaces product alerts the user and says that the connection has been lost. That is kind of a worst-case scenario and you would have to hit the refresh button on your browser in order to get your portlet back.

One of the best practices that I recommend is, there is a timeout feature - let's say it is 30 minutes. The ICEfaces timeout is configurable. It is actually measured in milliseconds. It is a setting in web.xml. The servlet spec also has a session timeout, but that is measured in seconds so you have to do a little bit of math, but my recommendation, the best practice is to make those match so that if you are logged into a portal like Liferay, your session is going to expire after a while.

Kito That's a good idea.
Neil Okay, and so if you make the ICEfaces timeout match the servlet session content timeout, then everything will be fine.
Kito Right, okay so it sounds like you have kind of a great combination of the two with ICEfaces and Liferay.
Neil Liferay kind of takes the position that we would like to see all of these technologies work in every scenario. It is kind of hard.
Kito Yeah, yeah, but it's a good thing.
Neil Liferay is a product where it runs in many different application servers and many different servlet containers: Resin and Jetty and Tomcat, Glassfish, JBoss and WebSphere. So in that sense you have a lot of choice as to what application server or servlet container you use. Sometimes an organization has already paid a lot of money for one, so that is what they have to use. So you can slide Liferay into that. Also, with the database, maybe you are in Oracle shop or MySQL shop, or Sybase even, or SQL server... Liferay tries to take the position of having its database schema work in any of the popular databases.
Kito I remember that big grid of all the application servers...
Neil There are like 700-800 deployment combinations for Liferay Portal.
Kito I know.
Neil ICEfaces, interestingly enough, is in the same type of boat, where they have all these different servlet containers and application servers that they need to support, Seam and different environments, portlets, servlets. So their matrix is also very, very, very complex, what they need to support.
Kito Right. Okay, so I guess it is worthwhile to point out that Liferay, like ICEfaces, is open source, right?
Neil Yes.
Kito Basically it is the same business model. You can get support and services from Liferay for its portal server.
Neil Right. They are very similar companies in their business model and the main thing that both companies do is production support of their tools. There is also consulting that is done and training as well. I have written the JSF training for Liferay and I have also authored quite a bit of the ICEfaces training as well. That is one of the things that I do, I am a trainer. I will conduct Liferay training, ICEfaces training, depending on the customers. There is a partnership between the companies such that we can share training materials, so that our mutual customers benefit.
Kito Alright Neil, anything else you want to add?
Neil No I think we covered pretty much everything Thanks for the opportunity to talk. I am looking forward to it.
Kito Okay. Well, hopefully we will see you at JSFOne next year.
Neil Hope to be here.
Kito Take it easy.
Neil Thanks.
Announcer That's it for this edition of the JSFCentral podcast .The music for this podcast was composed and performed by Kito Mann.


RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.