Neil Griffin

Utilizing instance storage (ephemeral storage) with RHEL on Amazon EC2

2011-09-03T10:54:07Z

Introduction

I recently had the opportunity to launch an Amazon EC2 instance and setup Liferay & MySQL. There were a couple of hurdles that I had to overcome, so I thought I would share the solutions I came up with.

Storage: Ephemeral or EBS?

When you launch an RHEL instance on EC2, the disk storage that is provided is a VERY SMALL (7 GB or less) root partition that is contained within the instance itself. This type of storage is called ephemeral. The benefit of ephemeral storage is that it doesn't cost any extra money. The drawback is that it can't participate in the EBS backup solution provided by Amazon -- you'll need to backup files across the network instead. Depending on the size of the instance, you will be given additional ephemeral storage, which is where you can potentially store data or install an app server for Liferay. The Amazon documentation indicates that this will be mounted automatically on /ephemeral0 but I found that this wasn't the case. You will need to use the "fdisk -l" command to find out the device name of the additional ephemeral storage. In my case, I found that the device was named /dev/xvdj. However, there was no filesystem on it, and it wasn't mounted. So you'll need to execute commands like the following:

mkfs -t ext4 /dev/xvdj

mkdir /ephemeral0

echo "/dev/xvdj /ephemeral0 ext4 defaults 1 2" >> /etc/fstab

mount /ephemeral0

The alternative storage is called EBS. The benefit is that it can participate in the Amazon backup solution, but the drawback is that it costs extra money. If you want to use EBS instead of ephemeral, you can create EBS Volumes using the Amazon Management Console and then attach them to your instance. Bear in mind that you'll still need to discover the device with "fdisk -l", put a filesystem on it, mount it, etc.

Moving MySQL to the additional ephemeral storage

In order to utilize the larger ephemeral storage for database files, I needed to move the MySQL data files from /var/lib/mysql to a filesystem mounted on /ephemeral0. I tried to follow the instructions in section 10.4.1 of the HREL documentation titled "MySQL Changing Database Location" but when I restarted mysqld via "service mysqld start" it reported FAILED, and the following was found in /var/log/mysqld.log:

110902 11:35:42 mysqld_safe Starting mysqld daemon with databases from /opt/var/mysql

110902 11:35:42 [Warning] Can't create test file /opt/var/mysql/domU-12-31-39-09-AE-12.lower-test

/usr/libexec/mysqld: Can't change dir to '/opt/var/mysql/' (Errcode: 13)

110902 11:35:42 [ERROR] Aborting

The irony here is that section 10.4.1 is meant to show you how to avoid this error. So I had to find a different approach, and found inspiration in the following articles:

The strategy I used was to copy the MySQL files to /ephemeral0, and then mount the ephemeral storage directory back to /var/lib/mysql

Step 1: Stop the MySQL server and copy the data files over to /ephemeral0:

[root@server]# service mysqld stop

[root@server]# cd /var/lib

[root@server]# tar cf - mysql/ --selinux | (cd /ephemeral0/var/lib; tar xvfp -)

NOTE: It's really important to keep the --selinux switch so that the SELinux context for each file will be saved in the tarball. Also, it's really important to keep the "p" switch upon extraction, so that file permissions will be preserved.

Step 2: Determine the existing selinux settings and re-apply them on a similar var/lib folder structure on /ephemeral0:

[root@server]# ls -lZ / | grep var

drwxr-xr-x. root root system_u:object_r:var_t:s0 var

[root@server]# chcon -u system_u -r object_r -t var_t /ephemeral0/var

[root@server]# ls -lZ /var | grep lib

drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 lib

[root@server]# chcon -u system_u -r object_r -t var_t /ephemeral0/var/lib

[root@server]# ls -lZ /var/lib | grep mysql

drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql

Step 3: Re-create the /var/lib/mysql mount point and preserve ownership/group/selinux settings:

[root@server]# cd /var/lib

[root@server]# mv mysql mysql.orig

[root@server]# mkdir mysql

[root@server]# chown mysql mysql

[root@server]# chgrp mysql mysql

[root@server]# chcon -u system_u -r object_r -t mysqld_db_t mysql

Step 4: Mount the directory that contains the MySQL data onto the /var/lib/mysql mount point and restart MySQL:

[root@server]# echo "/ephemeral0/var/lib/mysql /var/lib/mysql none bind bind" >> /etc/fstab

[root@server]# mount /var/lib/mysql

[root@server]# service mysqld start

Conclusion

The benefit of using this approach is that I didn't have to change any of the settings in the /etc/my.cnf configuration file. Also, I didn't have to fight the selinux security context problem. This approach can also be used for mounting other folders like /opt in order to utilize ephemeral storage.

Fixing SunCertPathBuilderException caused by Maven downloading from self-signed repository

2011-10-17T22:28:06Z

If you have a Maven repository running under https with a self-signed certificate, then building a Maven project can report the following error:

Error transferring file: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

There was an Oracle blog posted by Andreas Sterbenz back on Oct 09, 2006 that helped me diagnose the problem, but that blog is no longer available. Thankfully Andreas' blog was re-posted here. For additional information, I found another blog post that was helpful.

Anyways, I fixed this problem by downloading and compiling the source for InstallCert.java and running the following command:

java com.aw.ad.util.InstallCert myhostname.mydomain.com

This generated a file named jssecacerts in the current directory.

On Windows/Linux, this file needs to be copied to the JAVA_HOME/jre/lib/security/ directory.

On Mac needs to be copied to the JAVA_HOME/lib/security/ directory.

After I did this, Maven was able to download the artifacts from the self-signed repository.

Lightning fast portlet development with JRebel

2011-07-22T21:54:48Z

Back in April of this year I had the opportunity to speak at the CON-FESS conference in Vienna, Austria. One of the exhibitors there was zeroturnaround.com and I had the privilege of sitting next to founder Jevgeni Kabanov over dinner one night.

Jevgeni described the benefits of JRebel, a JVM-plugin that makes it possible for Java developers to instantly see any code change made to an app without redeploying. Needless to say, redeploying WARs is part of the very fabric of a Liferay portlet developer's life, so I knew that I had to give this product a try with my next ICEFaces 2 portlet with PortletFaces Bridge.

and to my utter amazement... IT WORKED!!!

Simply put, this product is a MUST HAVE for Liferay portlet developers. I'm hooked! Over the past 6 years of portlet development, this product could have saved me COUNTLESS hours of development time waiting for redeploys.

The JRebel documentation is quite good, but here are some quick instructions for how to get started with JRebel and the Liferay+Tomcat bundle:

Download JRebel (30 day free trial)
Install JRebel to it's default location. For example, on the Mac: /Applications/ZeroTurnaround/JRebel

Set the REBEL_HOME environment variable. On the Mac, I find it's best to do this inside the $HOME/.MacOSX/environment.plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"> <dict>
<key>REBEL_HOME</key>
<string>/Applications/ZeroTurnaround/JRebel</string>
</dict>
</plist>

On Mac, add the following to the LIFERAY_HOME/tomcat/bin/setenv.sh script:
```
-javaagent:$REBEL_HOME/jrebel.jar
```
On Windows, add the following to the LIFERAY_HOME/tomcat/bin/setenv.bat file:
```
-javaagent:%REBEL_HOME%\jrebel.jar
```
Create a rebel.xml file that will be deployed in the runtime classpath of the WAR:Note that if you install the JRebel plugin for Eclipse, IntelliJ 8/9, IntelliJ X, or NetBeans) you can right click on the project and have the IDE generate the file. You can also generate the rebel.xml file with a Maven goal.
- Maven: src/main/resources/rebel.xml
- Liferay Plugins SDK: docroot/WEB-INF/src/rebel.xml
Start Tomcat with the liferay/tomcat/bin/startup.sh script (startup.bat on Windows)
Deploy the WAR to the Liferay /deploy folder
Make some Java code changes to your app and click Save in your IDE
Reload your browser, and voila! Instant changes! No redeploy!

Working with JSF's and java.util.Date

2010-07-30T18:00:04Z

During a recent class I taught on ICEfaces, one of my students asked me why the calendar was often one day off from what got posted back to the model managed-bean setter.

For example:
// Facelets XHTML Markup: <ice:selectInputDate value="#{modelManagedBean.dateOfBirth}"> <f:convertDateTime pattern="MM/dd/yyyy" /></ice:selectInputDate>// Java Code import java.util.Date;public class ModelManagedBean { private Date dateOfBirth; public Date getDateOfBirth() { return dateOfBirth; } public Date setDateOfBirth(Date dateOfBirth) { SimpleDateFormat dateFormat = new SimpleDateFormat("MM/dd/yyyy hh:mm z"); // The value printed here during postback was often wrong by 1 day System.out.println("dateOfBirth=" + dateFormat.format(dateOfBirth)); this.dateOfBirth = dateOfBirth; } }

Basically, the JSF DateTimeConverter Javadoc states that if the timeZone attribute is not specified, then the default is GMT. But when you create an instance of java.text.SimpleDateFormat, the default TimeZone is equal to TimeZone.getDefault() which (for me) was EST. So the solution I explained to my students was to make sure we were comparing apples-to-apples the whole way through, by using GMT for the SimpleDateFormat printing, like this:

dateFormat.setTimeZone(TimeZone.getTimeZone("GMT"));
And of course, I think it's the recommended practice to run your application server JVM in GMT. That would eliminate the problem entirely. But when you're using Eclipse and Tomcat for development, that's typically not the case.

JSF 2.0 Complete Reference, with JSF Portlet Appendix

2010-07-30T18:47:55Z

I'm pleased to announce the new JSF 2.0 Complete Reference book by Ed Burns and Chris Schalk, published by McGraw-Hill. During the planning stages, Ed asked me to be a contributing author and help bring the first edition of the book up-to-date with JSF 2.0, and also to write a JSF Portlet Appendix.

As listed in the Table of Contents, Appendix A discusses the following Topics:

Overview of Portlet 1.0 and 2.0
- Portlet Lifecycle
- Portlet Modes
- Portlet Window States
- Portlet Preferences
- Inter-Portlet Communication
JSF Portlet Development
- JSF Portlet Bridges
- JSF Portlet View Handlers
- JSF ExernalContext and the Portlet API
- JSF and Portlet Preferences
- JSF and Inter-Portlet Communication
ICEfaces Portlet Development
- ICEfaces Ajax with Partial Submit
- ICEfaces Direct-to-DOM RenderKit
- The ice:portlet Tag
- ICEfaces 1.x Portlet Bridge
- ICEfaces 1.x D2DFaceletViewHandler
- ICEfaces 1.x and Portlet Window States
- ICEfaces Portlets and Concurrent DOM Views
- ICEfaces 1.x Extended Request Scope
- ICEfaces Ajax Push and Inter-Portlet Communication
- ICEfaces Themes and Portal Themes
- ICEfaces Themes and Liferay Themes
- ICEfaces Ajax Bridge and Liferay Portal
- ICEfaces Portlets and Liferay Request Attributes
PortletFaces
- Downloading PortletFaces
- PortletFacesContext
- PortletFaces Tags
- PortletFaces and Portlet Preferences
- PortletFaces and Expression Language Additions
- PortletFaces and Localization
- Liferay Language Portlet Integration
- Improved Integration Between Liferay and ICEfaces 1.x

This week (Feb 2nd to Feb 5th) Ed Burns & Chris Schalk will be helping to answer questions about the new book at JavaRanch. In addition, JavaRanch will be giving away a free copy of the book.

Finally I'd like to express my gratitude to Liferay, ICEsoft, Mimacom, and Triton for their generous support in making the JSF Portlet Appendix possible.

JSF 2.0 + ICEfaces 2.0 + Portlet 2.0 = The PortetFaces Bridge

2011-03-28T17:26:27Z

UPDATE#1: PortletFaces Bridge webinar took place on Thursday, Feb 11 2010 AD. Click here to view the PDF slideshow.

UPDATE#2: The source code is at Alpha1 status and can be checked out from SVN here:

I'm working on a new project called the PortletFaces Bridge which will enable the use of JSF 2.0 within Portlet 2.0 compliant portals like Liferay 5.x. The bridge implements a subset of the features available in JSR-329. Although the JSR-329 standard defines an API for a JSF 1.2 + Portlet 2.0 bridge, the PortletFaces Bridge is targeting JSF 2.0. Additionally, the bridge will facilitate usage of ICEfaces 2.0 within Liferay Portal.

Project Status as of January 27, 2010 AD:

I have a sample JSF 2.0 portlet developed that is using the new PortletFaces Bridge.
HTTP GET of portal page: bridge runs the portlet RENDER_PHASE, which runs the JSF lifecycle+renderResponse and the portlet renders fine in the browser.
HTTP POST after clicking h:commandButton: bridge runs the portlet ACTION_PHASE, which runs the JSF lifecycle. It then runs the portlet RENDER_PHASE, which runs the JSF renderResponse and the portlet renders fine in the browser.
RESOURCES: When using the new JSF 2.0 "resource" mechanism (like for downloading the "jsf.js" JavaScript file), the bridge correctly invokes the portlet RESOURCE_PHASE, which invokes the JSF 2.0 ResourceHandler and the contents of the requested resource are correctly delivered back to the browser.
AJAX: After tabbing-out of a field, the JSF 2.0 "jsf.js" JavaScript code correctly invokes the portlet RESOURCE_PHASE, which runs the JSF lifecycle+renderResponse, and correctly applies the DOM updates in the browser. Currently it uses the new JSF 2.0 <f:ajax /> tag to do Ajax requests. BTW I had to fix a problem in Mojarra to make this work -- I'm in contact with the Mojarra team and they're working on fixing it for the upcoming 2.0.3 release.
What's left: There's a bunch of little things -- loose ends that need to be coded up. Stuff like:
- Testing of ICEfaces 2.0 WITHOUT the <f:ajax /> tag
- Testing of ICEfaces 2.0 components (compatibility components)
- Testing of ICEfaces 2.0 Ajax Push
- After navigation-rules fire, need to compute the next JSF viewId to render
- Detecting portlet mode changes (VIEW MODE, EDIT MODE, HELP MODE)

The goal is to have an Alpha version ready for use by the time the webinar happens on Thursday, Feb 11 2010 AD. The bridge will be be an open source project and be available for download from the http://www.portletfaces.org website.

Speaking at JSF Summit: Social Networking with ICEfaces and Liferay

2009-11-18T17:29:41Z

I'll be speaking at JSF Summit 2009.

The event is being held from 12/1 - 12/4

Location:
Loews Portofino Hotel @ Universal Orlando
5601 Universal Boulevard
Orlando, FL 32819

Session Title:

Social Networking with ICEfaces and Liferay

Session Abstract:

This talk will demonstrate how easy it is to develop social networking portlets with ICEfaces and Liferay. Attendees will learn the fundamental techniques through code walkthroughs of ICE Friends and ICE Chat portlets, leveraging Facelets composite components and real-time status updates via Ajax Push.

Social networking is a natural addition to the portal, already a meeting place for applications. Diverse systems and users can be brought together for web-based communication and collaboration. When introduced to Ajax Push, portlets provide real-time communication features such as presence, chat, and new forms of application-specific interaction. Attendees will also learn about PortletFaces, a new open source project that enables a more JSF-centric approach to building portlets that use vendor-specific features of Liferay Portal.

PortletFaces Webinar

2009-10-27T18:30:37Z

I'm pleased to announce that the PortletFaces project has now been formally established and can be found here: http://www.portletfaces.org

An ICEsoft+Mimacom webinar has been scheduled for Thursday October 29, 2009:

4PM - 5PM CET
11AM - 12PM EDT
8AM - 9AM PDT

Here's the registration link: https://www1.gotomeeting.com/register/741441337

I'll be conducting the webinar along with Micha Kiener of Mimacom, sponsor of the Edoras Framework.

The goal the PortletFaces project is to make it easier to develop JSF portlets that run within Liferay Portal. The project contains a wealth of features that expose the standard features of the Portlet 2.0 API and vendor-specific features of Liferay in a way that is natural to JSF development. It also provides improved integration between Liferay and ICEfaces 1.x portlets.

The beginnings of PortletFaces can be traced back to a forum post made by community member Joel Kozikowski back in May of 2007. Joel donated his code to Liferay and we began to work on the project together under Liferay incubation. Since then, PortletFaces has been adopted by Mimacom AG and is a sub-project of the edoras framework.

I'd like to personally thank Joel and the other contributors for their valuable additions to PortletFaces:

Micha Kiener
Atul Patel
Ed Shin
Stefan Niederhauser

Also my personal thanks to Liferay for sponsoring PortletFaces during incubation, ICEsoft for all the terrific support, and thanks to Mimacom for adopting the project.

Finally, I'd like to thank Triton's Steve Groninga for coming up with the PortletFaces project logo.

Documentation for PortletFaces can be found here: http://www.portletfaces.org/documentation

JSF 2.0 Test Drive Part 2: Developing a Website with Facelets Templating

2010-12-20T19:40:40Z

As part of my work on JSR 314 (JSF 2.0) I've been reviewing the specification, Javadocs, and tag library docs for accuracy. One way I do this is to make examples that test drive what the documentation says JSF 2.0 will do.

In Part 1 of this series, I showed how to develop an Ajaxified JSF 2.0 Facelet Composite Component.

Now here's Part 2 of my JSF 2.0 Test Drive... Developing a Website with Facelets Templating

Facelets Templating

Templating -- what's that? Well templating refers to a technology that you would use to control the layout and content of a website. It's kind of like Liferay Portal's "Layout Template" feature that lets you control how portlets are arranged on the portal page.

The premiere view-handler in JSF 2.0 is Facelets, which provides a powerful templating engine designed especially for JSF. Websites typically have a layout of sections that is common for all pages: header, navigation, main content, and footer. That's where Facelets Templating comes in to save the day.

Downloadable Source Code

The Maven 2 project source code is licensed under the MPL 1.1 and is available at the edoras framework SVN repo:

http://svn.portletfaces.org/svn/portletfaces/legacy/examples/trunk/webapps/org.edorasframework.example.facelet.template.jsf.2.0/

Home Page Screen Shot

Here is a screen shot of the home page for the website:

The "Welcome Our Company Website" light-gray rectangle at the top is the "header" of the website. This is kind of like a banner that is to appear at the top of every web page in the site. It typically never changes.

The Home, Products, and Contact Us links are part of the "navigation" for the site. The links typically change a little from page to page in a real world site.

The "Welcome to the HOME page" dark-gray rectangle on the right is the "main" content for each page. This is the content in this part typically changes quite a bit for each page.

The "Copyright" light-gray rectangle on the bottom is the "footer" for the website. Like the header, it typically never changes.

Template Source Markup: template.xhtml

Here is the markup for the template. It's basically a Facelets f:view that specifies an h:panelGroup (renders a <div> layer) for the header, and another for the footer. Note that those sections use the Facelets ui:include tag in order to insert the contents of the header and footer info, which lives in separate XHTML files. In the middle is an h:panelGrid, which renders a two-column HTML <table>. Note the Facelets ui:insert tags -- they are kind of like markers that indicate that something will be inserted at runtime. More on that when we look at the ui:define tags in the Home page. Also, note that the Facelets ui:debug tag is specified in the template -- that's kind of a best practice for helping JSF developers debug the server-side state of things.

<f:view xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core"
  xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.w3.org/1999/xhtml http://www.w3.org/2002/08/xhtml/xhtml1-transitional.xsd">

  <!-- Enables CTRL+SHIFT+D for activating Facelets debug window -->
  <ui:debug />

  <html>
  <h:head>
    <ui:insert name="htmlHead" />
    <link rel="stylesheet" type="text/css" href="css/template.css" />
  </h:head>
  <h:body>
    <h:panelGroup layout="block" styleClass="header">
      <ui:include src="/WEB-INF/includes/header.xhtml" />
    </h:panelGroup>
    <h:panelGrid columns="2" columnClasses="nav-col, main-col" styleClass="middle-table">
      <h:panelGroup layout="block">
        <h:form>
          <ui:insert name="navigation" />
        </h:form>
      </h:panelGroup>
      <h:panelGroup layout="block">
        <ui:insert name="main" />
      </h:panelGroup>
    </h:panelGrid>
    <h:panelGroup layout="block" styleClass="footer">
      <ui:include src="/WEB-INF/includes/footer.xhtml" />
    </h:panelGroup>
  </h:body>
  </html>
</f:view>

Home Page Source Markup: home.xhtml

Here's the markup for the home page. Note that it's not a Facelets f:view at all -- instead its a ui:composition that specifies template.xhtml as the Facelet template to be used for rendering. The main thing to point out here is that the ui:define tag "defines" the content that is to be inserted into the template via the corresponding ui:insert tag found in the template.

<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html"
  xmlns:f="http://java.sun.com/jsf/core" xmlns:ui="http://java.sun.com/jsf/facelets"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.w3.org/1999/xhtml http://www.w3.org/2002/08/xhtml/xhtml1-transitional.xsd"
  template="/WEB-INF/includes/template.xhtml">

  <ui:define name="htmlHead">
    <meta name="description" content="Our Company Home Page" />
    <title>Our Company - Home</title>
  </ui:define>

  <ui:define name="navigation">
    <h:outputText styleClass="selected" value="Home" />
    <h:commandLink action="products" value="Products" />
    <h:commandLink action="contact-us" value="Contact Us" />
  </ui:define>

  <ui:define name="main">
    <h:outputText value="Welcome to the HOME page." />
  </ui:define>

</ui:composition>

The remainer of the files (header, footer, products page, contact-us page) are the SVN repos.

Again, hope you enjoyed seeing JSF 2.0 in action! Good stuff ahead!

JSF 2.0 Test Drive Part 1: Developing a Facelet Composite Component

2010-12-20T19:38:40Z

To that end, here's Part 1 of my JSF 2.0 Test Drive... Developing a Facelet Composite Component

Composite Component Tag

  <testcc:inputColor />

Description

An Ajaxified JSF 2.0 Facelet Composite Component that lets you choose an RGB color.

Downloadable Source Code

The Maven 2 project source code is licensed under the MPL 1.1 and is available at the edoras framework SVN repo:

http://svn.portletfaces.org/svn/portletfaces/legacy/examples/trunk/webapps/org.edorasframework.example.facelet.cc.jsf.2.0/

Screen Shot

JSF 2.0 Terminology

In order to understand some of the terms used in the example, let's talk about some new JSF 2.0 Facelet terminology found in the documentation:

Composite Component:	Refers to an XHTML file that contains a piece of reusable markup that is encapsulated by the ui:component tag
Composite Component Author:	Refers to the person that develops the composite component
Composite Component Tag:	Refers to a tag like <testcc:inputColor /> that lets folks create instances of the composite component
Using Page:	Refers to the Facelet XHTML f:view that contains the composite component tag
Page Author:	Refers to the person that that creates an instance of the composite component on a using page.

Composite Component Source: inputColor.xhtml

Here's the markup for the component itself. Note how JSF 2.0 now has a nice ui:interface section for defining the usage contract for the page author to abide by, and a ui:implementation section for hiding the inner workings of the component itself (the reusable markup). Also note that I didn't have to write any Javascript to perform Ajax updates in the DOM -- JSF 2.0 has that built-in with the f:ajax tag. The render attribute of f:ajax specifies a space-delimited list of "ids" that are to be re-rendered after the form is submitted via XmlHttpRequest().

<ui:component xmlns="http://www.w3.org/1999/xhtml" xmlns:c="http://java.sun.com/jsp/jstl/core"
  xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html"
  xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:cc="http://java.sun.com/jsf/composite"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.w3.org/1999/xhtml http://www.w3.org/2002/08/xhtml/xhtml1-transitional.xsd">

  <cc:interface>
    <cc:attribute name="value" required="true" type="org.edorasframework.example.Color">
      <cc:attribute name="red" required="true" />
      <cc:attribute name="green" required="true" />
      <cc:attribute name="blue" required="true" />
    </cc:attribute>
    <cc:actionSource name="colorPalette" targets="redSelector greenSelector blueSelector" />
    <cc:editableValueHolder name="colorFields" targets="redInputText greenInputText blueInputText" />
    <cc:facet name="header" required="true" />
  </cc:interface>

  <cc:implementation>
    <cc:renderFacet name="header" />
    <f:ajax render="preview kids">
      <h:panelGrid columns="2">
        <h:outputLabel value="R:" />
        <h:inputText id="redInputText" value="#{cc.attrs.value.red}">
          <f:validateLongRange minimum="0" maximum="255" />
        </h:inputText>
        <h:outputLabel value="G:" />
        <h:inputText id="greenInputText" value="#{cc.attrs.value.green}">
          <f:validateLongRange minimum="0" maximum="255" />
        </h:inputText>
        <h:outputLabel value="B:" />
        <h:inputText id="blueInputText" value="#{cc.attrs.value.blue}">
          <f:validateLongRange minimum="0" maximum="255" />
        </h:inputText>
      </h:panelGrid>
    </f:ajax>
    <h:outputText value="Color Preview: " />
    <c:set value="#{cc.attrs.value.red}" var="red" />
    <c:set value="#{cc.attrs.value.green}" var="green" />
    <c:set value="#{cc.attrs.value.blue}" var="blue" />
    <c:set value="#{red},#{green},#{blue}" var="rgb" />
    <h:outputText id="preview" value=" " style="border: 1px solid; padding: 1px 10px; background-color: rgb(#{rgb});" />
    <f:ajax render="redInputText greenInputText blueInputText preview kids">
      <h:panelGrid border="1" columns="3">
        <f:facet name="header">
          <h:outputText value="Color Palette" />
        </f:facet>
        <h:commandLink id="redSelector" value="Red">
          <f:setPropertyActionListener target="#{cc.attrs.value.red}" value="255" />
          <f:setPropertyActionListener target="#{cc.attrs.value.green}" value="0" />
          <f:setPropertyActionListener target="#{cc.attrs.value.blue}" value="0" />
        </h:commandLink>
        <h:commandLink id="greenSelector" value="Green">
          <f:setPropertyActionListener target="#{cc.attrs.value.red}" value="0" />
          <f:setPropertyActionListener target="#{cc.attrs.value.green}" value="255" />
          <f:setPropertyActionListener target="#{cc.attrs.value.blue}" value="0" />
        </h:commandLink>
        <h:commandLink id="blueSelector" value="Blue">
          <f:setPropertyActionListener target="#{cc.attrs.value.red}" value="0" />
          <f:setPropertyActionListener target="#{cc.attrs.value.green}" value="0" />
          <f:setPropertyActionListener target="#{cc.attrs.value.blue}" value="255" />
        </h:commandLink>
      </h:panelGrid>
    </f:ajax>
    <br />
    <h:panelGroup id="kids">
      <cc:insertChildren />
    </h:panelGroup>
  </cc:implementation>

</ui:component>

Using Page Source: usingPage.xhtml

Here's what the using page looks like, and how it creates an instance of the composite component by using a composite component tag. Note that with JSF 2.0, you can attach action-listeners and value-change-listeners to composite components. Additionally, you can specify children inside the composite component tag, provided that the composite component author uses the ui:insertChildren tag to place the children somewhere in the reusable markup. The testcc:inputColor tag shown below inserts an h:panelGrid as a child, which shows the "You Selected..." part to the user.

<f:view xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core"
  xmlns:h="http://java.sun.com/jsf/html" xmlns:testcc="http://java.sun.com/jsf/composite/testcc"
  xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.w3.org/1999/xhtml http://www.w3.org/2002/08/xhtml/xhtml1-transitional.xsd">
  <h:head>
    <title>Using Page</title>
  </h:head>
  <h:body>
    <h:form>
      <h:messages />
      <testcc:inputColor value="#{modelManagedBean.color}">

        <f:facet name="header">
          <h:outputText value="Please choose a color" />
        </f:facet>

        <f:actionListener for="colorPalette" type="org.edorasframework.example.ColorActionListener" />

        <f:valueChangeListener for="colorFields" type="org.edorasframework.example.ColorValueChangeListener" />

        <!--
        The following h:panelGrid will be used by the cc:insertChildren tag in the
        cc:implementation section of the  testcc:inputColor composite component.
        -->
        <h:panelGrid columns="2">
          <f:facet name="header">
            <h:outputText value="You Selected: " />
          </f:facet>
          <h:outputLabel value="Red:" />
          <h:outputText value="#{modelManagedBean.color.red}" />
          <h:outputLabel value="Green:" />
          <h:outputText value="#{modelManagedBean.color.green}" />
          <h:outputLabel value="Blue:" />
          <h:outputText value="#{modelManagedBean.color.blue}" />
        </h:panelGrid>

      </testcc:inputColor>
      <br />
      <h:commandButton value="Submit" />
    </h:form>
  </h:body>
</f:view>

Composite Component Value POJO: Color.java

Here is the POJO that is used to supply a value to the composite component:

package org.edorasframework.example;

import java.io.Serializable;

/**
 * This class provides a way of representing a color as an RGB triplet.
 *
 * @author  "Neil Griffin"
 */
public class Color implements Serializable {

  private static final long serialVersionUID = -3810147232196826614L;

  private int red;
  private int green;
  private int blue;

  public int getBlue() {
    return blue;
  }

  public int getGreen() {
    return green;
  }

  public int getRed() {
    return red;
  }

  public void setBlue(int blue) {
    this.blue = blue;
  }

  public void setGreen(int green) {
    this.green = green;
  }

  public void setRed(int red) {
    this.red = red;
  }

}

The remainer of the files (action listener, value change listener, model managed bean) are all available from the SVN repos.

Anyways, hope you enjoyed seeing JSF 2.0 in action! Good stuff ahead!

There's Gold in that Portal!

2009-10-05T00:55:23Z

On a recent trip to Colorado I had the opportunity to go panning for gold in a stream and take a tour of a gold mine. There may be a lot of gold in the West Portal (shown below), but rest assured I'm still hooked on Liferay. Although I enjoyed my time out there, it is good to be back home in Sunny, FL.

Jazoon 2009 Conference Video: Like Peanut Butter & Chocolate (or Ajax Meets Portals)

2010-04-02T15:08:03Z

Here is the video recording of the Jazoon 2009 talk I was privileged to do with Micha Kiener of Mimacom:

Presentation Title: Like Peanut Butter & Chocolate (or Ajax Meets Portals)

Direct link: http://www.parleys.com/#id=363&st=5&sl=38

Description: Discussion of how ICEfaces and Ajax Push can be used to perform Inter-Portlet-Communication (IPC) and also provides a rich Ajax-powered user experience.

You may need to click the triangle (play) button to get the movie to play.

Conference Talks: Social Networking Portlets with ICEfaces Ajax Push

2009-08-14T16:47:09Z

I have the privilege of speaking about Social Networking Portlets with ICEfaces Ajax Push at the following three conferences:

JSF Summit

Dec 1-4, 2009
Orlando, FL

CommunityOne West
Here I'll be co-speaking with Ed Burns, who is co-chairman of the JSR 314 (JSF 2.0) Expert Group

June 1-3, 2009
The Moscone Center
San Francisco
Map

This is an open developer conference. Monday 6/1 is free!

Liferay East Coast User Conference

May 21, 2009
Rivet Logic Corporation (Training Center)
1775 Wiehle Avenue, 3rd floor
Reston, VA 20190
Map

The talks will focus on the power and elegance of Liferay + ICEfaces Ajax Push, and how these technologies can be used together to create Social Networking portlets with Liferay Portal.

Social networking is a natural addition to portals, already a meeting place for applications. Diverse systems and users can be brought together for web-based communication and collaboration. When introduced to Ajax Push, Portlets can provide real-timecommunication features, such as presence, chat, and new forms of application-specific interaction.

Here's a screen shot of two portlets I'll be demontrating: ICEfaces Friends, and ICEfaces Chat:

The friends portlet is presence-aware, in that it has an application-scoped bean that listens to users logging-in/out of the portal. When it receives one of those events, ICEfaces Ajax Push will fire a visual effect, alerting the user of the friend's online status. If online, then the chat icon is activated. If the user clicks on the chat icon, then ICEfaces Ajax Push is used to achieve inter-portlet communication with the Chat portlet on the right. A new chat session is created, and users can chat with one another in near-real-time, again thanks to ICEfaces Ajax Push.

One of the things that I love about JSF, is the elegant, clean separation of the Model, View, and Controller concerns of the MVC design pattern. Case in point: Here's the entire XHTML markup for the Chat portlet:.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<f:view xmlns:c="http://java.sun.com/jstl/core"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:ice="http://www.icesoft.com/icefaces/component"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:sn="http://www.liferay.com/jsf/facelets/socialnetworking">
    <ice:portlet styleClass="portlet-content">
        <sn:styling />
        <ice:form>
            <ice:messages />
            <c:set value="#{chatRoomsModel.roomsWithUser}" var="chatRoomsWithUser" />
            <ice:panelTabSet rendered="#{!empty chatRoomsWithUser}" value="#{chatRoomsWithUser}" var="chatRoom">
                <ice:panelTab label="#{chatRoom.name}">
                    <ice:panelGroup id="scroller" style="overflow: auto; width: 100%; height: 250px;">
                        <ice:dataTable rowClasses="results-row,results-row alt"
                                width="100%" value="#{chatRoom.chatMessages}" var="chatMessage">
                            <ice:column style="width: 50px;">
                                <sn:friend
                                    portraitStyleClass="avatar" portraitWidth="30px" showJobTitle="false"
                                    showOnlineStatus="false" user="#{chatMessage.user}" />
                            </ice:column>
                            <ice:column>
                                <ice:outputText value="#{chatMessage.date}">
                                    <f:convertDateTime pattern="MM/dd/yyyy hh:mm:ss a" />
                                </ice:outputText>
                                <br />
                                <ice:outputText value="#{chatMessage.text}" />
                            </ice:column>
                        </ice:dataTable>
                    </ice:panelGroup>
                    <ice:inputText action="#{chatRoomsBacking.addMessage(chatRoom)}" value="#{chatRoomsBacking.messageText}" />
                    <ice:commandButton action="#{chatRoomsBacking.addMessage(chatRoom)}" value="#{message['add-message']}" />
                </ice:panelTab>
            </ice:panelTabSet>
        </ice:form>
    </ice:portlet>
</f:view>

Also, these portlets make heavy use of Facelets Composite Components, and demonstrate how you can create new JSF components entirely with XHTML markup.

Hope to see you at one of these conferences!

Podcast interview by Kito Mann of JSF Central regarding Liferay and ICEfaces

2009-05-06T12:16:09Z

Back in October 2008 at the JSFOne conference, I was interviewed by Kito Mann of JSF Central regarding Liferay and ICEfaces. The podcast and transcript were recently published at the JSF Central website:

http://www.jsfcentral.com/listings/R4013?link

Among the topics discussed are:

Liferay and JSF
Liferay and ICEfaces
JSR-314 JSF 2.0
JSR-301 JSF Portlet Bridge Standard
Liferay Roles and Security

Making distinctions between different kinds of JSF managed-beans

2009-04-15T23:19:40Z

JSF has a simple Inversion-of-Control (IoC) container called the JSF Managed Bean Facility (MBF). Although it has a verbose XML syntax, and is not as robust as the Spring BeanFactory, PicoContainer, or the JBoss Microcontainer, the MBF does have the basics of an IoC container, and offers features like dependency injection.

When a POJO is managed by the JSF MBF, it is typically referred to as a managed-bean. But if you're going to create a maintainable JSF webapp/portlet, it is necessary to distinguish between different kinds of managed-beans. This practice will also preserve the clean separation of concerns that JSF provides by implementing the Model-View-Controller (MVC) design pattern:

Managed-Bean Type	Nickname	Typical Scope
Model Managed-Bean	model-bean	session
Description: This type of managed-bean participates in the "Model" concern of the MVC design pattern. When you see the word "model" -- think DATA. A JSF model-bean should be a POJO that follows the JavaBean design pattern with getters/setters encapsulating properties. The most common use case for a model bean is to be a database entity, or to simply represent a set of rows from the result set of a database query.
Backing Managed-Bean	backing-bean	request
Description: This type of managed-bean participates in the "View" concern of the MVC design pattern. The purpose of a backing-bean is to support UI logic, and has a 1::1 relationship with a JSF view, or a JSF form in a Facelet composition. Although it typically has JavaBean-style properties with associated getters/setters, these are properties of the View -- not of the underlying application data model. JSF backing-beans may also have JSF actionListener and valueChangeListener methods.
Controller Managed-Bean	controller-bean	request
Description: This type of managed-bean participates in the "Controller" concern of the MVC design pattern. The purpose of a controller bean is to execute some kind of business logic and return a navigation outcome to the JSF navigation-handler. JSF controller-beans typically have JSF action methods (and not actionListener methods).
Support Managed-Bean	support-bean	session / application
Description: This type of bean "supports" one or more views in the "View" concern of the MVC design pattern. The typical use case is supplying an ArrayList<SelectItem> to JSF h:selectOneMenu drop-down lists that appear in more than one JSF view. If the data in the dropdown lists is particular to the user, then the bean would be kept in session scope. However, if the data applies to all users (such as a dropdown lists of provinces), then the bean would be kept in application scope, so that it can be cached for all users.
Utility Managed-Bean	utility-bean	application
Description: This type of bean provides some type of "utility" function to one or more JSF views. A good example of this might be a FileUpload bean that can be reused in multiple web applications.

Now... One of the main benefits in making fine distinctions like this is loose coupling. What's that you ask? Well let's first take a look at an example of tight coupling, where MVC concerns can be smashed/confused into a single managed-bean:

public class ModelAndBackingAndControllerBean {

	private String fullName; // model-bean property
	private boolean privacyRendered; // backing-bean property

	// model-bean getter
	public String getFullName() {
		return fullName;
	}
	
	// model-bean setter
	public void setFullName(String fullName) {
		this.fullName = fullName;
	}

	// backing-bean getter
	public boolean isPrivacyRendered() {
		return privacyRendered;
	}

	// backing-bean setter
	public void setPrivacyRendered(boolean privacyRendered) {
		this.privacyRendered = privacyRendered;
	}

	// backing-bean actionListener for UI support logic
	public void togglePrivacySection(ActionEvent actionEvent) {
		privacyRendered = !privacyRendered;
	}

	// controller-bean business logic
	public String submit() {
		System.out.println("fullName=" + fullName);
		return "success";
	}
}

The problem here is that the bean would have to be kept in session scope because of the model-bean property. Additionally, what if we wanted to do some unit testing with mock model data? Can't do it. So in order to fix these problems, and to promote loose coupling, we would have three separate Java classes:

public class ModelBean {

	private String fullName;

	public void setFullName(String fullName) {
		this.fullName = fullName;
	}

	public String getFullName() {
		return fullName;
	}
}

public class BackingBean {

	private boolean privacyRendered;

	public void setPrivacyRendered(boolean privacyRendered) {
		this.privacyRendered = privacyRendered;
	}

	public boolean isPrivacyRendered() {
		return privacyRendered;
	}

	public void togglePrivacySection(ActionEvent actionEvent) {
		privacyRendered = !privacyRendered;
	}

}

public class ControllerBean {

	private ModelBean modelBean;
	
	public ModelBean getModelBean() {
		return modelBean;
	}

	public void setModelBean(ModelBean modelBean) {
		// Dependency injected from the JSF managed-bean facility
		this.modelBean = modelBean;
	}

	public String submit() {
    	System.out.println("fullName=" + getModelBean().getFullName());
        return "success";
    }

}

Now that the beans are found in different classes, they can all be kept in their appropriate scopes. The model-bean can be kept in session scope, and the backing-bean and controller-bean can be kept in request scope, thus saving memory resources on the server.

Finally, we can use the dependency injection features of the JSF MBF in order to inject the model-bean into the controller-bean. This can be seen in the following WEB-INF/faces-config.xml example, where the #{modelBean} Expression Language (EL) binding is used:

<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
	version="1.2">
	<managed-bean>
		<managed-bean-name>modelBean</managed-bean-name>
		<managed-bean-class>myproject.ModelBean</managed-bean-class>
		<managed-bean-scope>session</managed-bean-scope>
	</managed-bean>
	<managed-bean>
		<managed-bean-name>backingBean</managed-bean-name>
		<managed-bean-class>myproject.BackingBean</managed-bean-class>
		<managed-bean-scope>request</managed-bean-scope>
	</managed-bean>
	<managed-bean>
		<managed-bean-name>controllerBean</managed-bean-name>
		<managed-bean-class>myproject.ControllerBean</managed-bean-class>
		<managed-bean-scope>request</managed-bean-scope>
		<managed-property>
			<property-name>modelBean</property-name>
			<value>#{modelBean}</value>
		</managed-property>
	</managed-bean>
</faces-config>

Lazy Loading a JSF DataModel for an ICEfaces ice:dataTable

2008-11-06T00:10:07Z

Iterator components like the JSF h:dataTable and ICEfaces ice:dataTable have two special attributes: value and var. The value attribute is typically bound to a JSF model-managed-bean, and the var attribute introduces a new variable into the JSF Expression Language (EL) like this:

<ice:dataTable value="#{modelBean.rows}" var="row"> <ice:column> <f:facet name="header"> <ice:outputText value="#{msgs.firstName}" /> </f:facet> <ice:outputText value=#{row.firstName}" /> </ice:column> ... </ice:dataTable>

The ModelBean.getRows() method can return a variety of types, but in my experience the most typical one is a generic java.util.List like this:

public List<Row> getRows() {...}

Under the hood, JSF is expecting the value attribute to contain an instance of a JSF DataModel object. In fact, if you don't return a DataModel, JSF will implicitly wrap your return value with a wrapper class, such as the ListDataModel for values of type java.util.List.

Typically, the model bean that contains the data is kept in JSF session scope or ICEfaces extended-request scope. This is fine if you only have 10 or 20 rows in the result set, but what if you have 1,000,000 rows? Obviously there is a scalability concern in such a case, especially since the user is only going to be viewing 10 or 20 rows at a time in the browser.

Unfortunately, the JSF spec does not provide a way of loading data on demand (popularly known as "lazy loading"). I've seen several posts on how to do this, but I thought it would be nice to develop a persistence-technology-independent solution.

To this end, I wrote an abstract class named LazyDataModel.java that is meant to be subclassed into a concrete implementation. Feel free to download the LazyDataModel.java (zipped) source code.

Here are the three methods you will need to supply in your concrete implementation:

public abstract int getRowsPerPage(); public abstract int countRows(); public abstract List<DTO> findRows(int startRow, int finishRow);

The DTO marker implies that this class is meant to be used at the JSF UI layer of a portlet/webapp, and that it is meant to be used in conjunction with the Data Transfer Object design pattern (formerly known as the Value Object / VO design pattern).

BTW, in order for this to be of benefit to the end user, you'll need to connect an ICEfaces ice:dataPaginator component to the ice:dataTable iterator. That will provide icons for navigation such as first-page, previous-page, next-page, and last-page.

Webinar: Filthy Rich Portlets with ICEfaces and Liferay

2011-03-17T18:29:50Z

UPDATE: March 17, 2011

This blog post refers to an old version of ICEfaces (1.8). I would encourage you to try out the ICEfaces 2 versions of these portlets here: http://www.portletfaces.org/portletfaces-bridge/examples

ORIGINAL POST FOLLOWS: September 30, 2008

Note: An archive of the webinar is now available on ICEfaces .org in both .wmv and quicktime:
http://www.icefaces.org/main/resources/webinars.iface (3rd item in the Archive Webinar list)

Also, here is a video+transcript of a similar presentation given at the JSFOne conference:
http://java.dzone.com/videos/filthy-rich-portlets

Webinar Title: Filthy Rich Portlets with ICEfaces and Liferay

Webinar Date/Time: Tuesday, October 14, 2008 1:00 PM - 2:00 PM EDT

Webinar Link: https://www1.gotomeeting.com/ojoin/451479046/1859554

Webinar Slides and Demo Downloads:

Filthy Rich Portlet Slides (PDF, 5.8MB)
Source code for Demo #1: JSF Portlet (Liferay Plugins SDK ZIP, 1.4 MB)
Source code for Demo #2: ICEfaces Portlet (Liferay Plugins SDK ZIP, 4.7 MB)
Source code for Demo #3: JSF IPC Portlet (Liferay Plugins SDK ZIP, 1.4 MB)
Source code for Demo #4: ICEfaces IPC Ajax Push Portlet (Liferay Plugins SDK ZIP, 4.7 MB)

The sources are meant to be extracted into the "plugins" folder of the Liferay Plugins SDK. Fore more info, download the the Liferay Plugins SDK documentation.

Webinar Overview:

Portals and Portlets
Liferay Portal
JSF Portlets
ICEfaces Portlets
Standard Inter-Portlet Communication
Ajax Push Inter-Portlet Communication

Filthy Rich Portlets with ICEfaces at the JSFOne Conference!

2008-11-05T20:09:08Z

UPDATE!

Here is a video+transcript of the presentation given at the JSFOne conference:
http://java.dzone.com/videos/filthy-rich-portlets

And here is a similar webinar on ICEfaces .org in both .wmv and quicktime:
http://www.icefaces.org/main/resources/webinars.iface (3rd item in the Archive Webinar list)

The JSFOne conference is being held from Thu 9/4/2008 - Sat 9/6/2008 in the Washington, DC area. Specifically, the event is being held at the Sheraton Premier Hotel in Vienna, VA.

I have the great privilege of speaking at the conference, and will be doing a talk titled "Filthy Rich Portlets with ICEfaces and Liferay." To that end, I recently committed a new portlet to the Liferay Plugins trunk: sample-icefaces-ipc-ajax-push-portlet.

It's actually one web archive (WAR) that contains two portlets. The Customers portlet simply shows a list of customers:

When the user clicks on a customer, ICEfaces initiates an Ajax-Push event which updates the Bookings portlet with travel plans of the selected customer:

But wait! There's more -- the IPC is bi-directional in the sense that if I change the first name or last name in the Bookings portlet, then the name will be updated in the Customers portlet too, all thanks to ICEfaces Ajax Push.

See you at JSFOne!

Switched from Windows to Mac

2008-08-21T00:35:50Z

Perhaps I'm dating myself, but when I entered college in 1988, the Computer Science department required me to buy a Mac II because it was the only personal computer of the day that ran a type of Unix. No, not Mac OS X silly, but A/UX. I never really used the Mac OS back then -- always did my projects under A/UX. Recently my buddy Ed Burns invited me to a "classic arcade game" exhibit at the Orlando Science center, and there happened to be an exhibit of Apple computers that was the personal collection of someone on display. You guessed it, there was a Mac II on display! Yes, that's right -- the computer I used in college was in a museum. Hey, it had an 80MB hard drive, and all my engineering friends only had 20MB drives in their IBM PCs running MS-DOS.

After I graduated, I sold my Mac II to another student. My first job had me using Windows 3.1, and I've been using Microsoft operating systems as a desktop OS ever since. I moved to Windows 95, NT4, Windows 2000, XP, and finally Vista.

I found that fresh installs of Windows XP were nice and fast. But after installing/uninstalling programs, Windows would catch a sickness that would make the OS slow down. I found that every 3-6 months I had to wipe my hard drive and reinstall XP in order to get it back to top speed. My experience with Vista was much the same. After it got slow a second time, I decided I needed a change.

I almost went with Ubuntu Linux, but I had a non-Liferay email account that required Microsoft Exchange connectivity. So I ended up going with the Mac.

Yes, after 20 years (almost to the very day), I'm driving a Mac again. How about that!

Sharing Data Between Portlets

2008-09-02T23:34:24Z

If you want to share data between portlets, a common way to do that is by storing data in the user's session. Liferay Portal has some nice features for sharing session data like <shared-session-attributes> in the liferay-portlet.xml file, and shared.session.attributes in the portal-ext.properties file.

But what if you're trying to go session-less? Or what if you want to share data globally for all users across sessions?

One way to do share data like this is to store the data in the portal's ROOT context. The first step is to create a GlobalStartupAction in the Liferay EXT environment, like this:

package com.foo.liferay.startup;

public class GlobalStartupAction extends SimpleAction {

	private static List<String> fooList; 
 	public List<String> getFooList() {
		return fooList;
	}

	public static void 
	@Override public void run(String[] ids) throws ActionException {
		// Cache all the data
		fooList = new ArrayList<String>();
		fooList.add(new String("red"));
		fooList.add(new String("green"));
		fooList.add(new String("blue"));
	}
}

Then, the GlobalStartupAction needs to be registered in the portal-ext.properties file. There is already a global startup action specified there for Liferay's own startup purposes, but thankfully this value can be a comma-delimited list, so we can just add the GlobalStartupAction after the Liferay one:

global.startup.events=com.liferay.portal.events.GlobalStartupAction,com.foo.liferay.startup.GlobalStartupAction

And then inside each portlet, use the magic Liferay PortalClassInvoker to call the static getFooList() method. The PortalClassInvoker utility figures out the classloader for the Liferay Portal context before calling the specified method:

import com.liferay.portal.kernel.util.PortalClassInvoker;

public class ApplicationScopeBean {

    private static final List fooList;

    public ApplicationScopeBean() {
        List<String> fooList = (List<String>) PortalClassInvoker.invoke("com.foo.liferay.startup.GlobalStartupAction", "getFooList"));

    }

}