Sharing Data Between Portlets

Company Blogs August 16, 2008 By Neil Griffin Staff

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"));
    }

}

 

Improving The Performance of Liferay's Ant-Based Build System

Company Blogs November 19, 2007 By Neil Griffin Staff

In recent days, some of the engineers at Liferay reported some amazing performance gains with Liferay's Ant build system by using Linux instead of Windows. Well this peaked my curiosity to say the least. I've been working exclusively with Windows XP on my desktop since around 2001, and have only used with Linux on servers -- never for my desktop. Well I'm a former Solaris / IRIX / DecUnix / HP-UX guy and so I decided to give Linux a try on the desktop.

I tried Fedora 7 first, but received a "too many open files" error when I tried to compile Liferay Portal with the "ant all" command. I tried messing with the limits.conf file but still wasn't able to get it working.

So I tried Ubuntu and I didn't receive the "too many open files" error. Woo hoo! BTW, I've got the Nvidia XGL driver going along with the Compiz Fusion window manager. Liferay developer James Min wasn’t kidding when he wrote to me “OS X, Vista... Watch out!” COMPIZ FUSION IS TOTALLY OUT OF CONTROL WAY COOL!!! Check out this movie to see for yourself. I’ve got the desktop cube thing working between Remote Desktop to Windows and Linux. I'm loving it! (On a semi-related side note, the IntelliJ IDEA user interface has a limitation where you can only open one project at a time. With virtual desktops, I might be able to work-around this limitation by having an IntelliJ project open on each virtual desktop.)

Well back to the Ant build system performance issue... Here are my unscientific test results -- not sorted, just grouped according to hardware:

Test#MachineHard DiskOSJDKCompilerBuild Time
1Pentium M 1.8 Ghz7200RPMWindows XPSun JDK 1.4Jikes8 minutes, 30 seconds
2Pentium M 1.8 Ghz7200RPMWindows XPSun JDK 5.0Jikes3 minutes, 52 seconds
Note that by changing JDK from 1.4 to 5.0 made the build
go more than 2x faster on Windows XP
3Pentium M 1.8 Ghz7200RPM32-bit Ubuntu 7.04Sun JDK 1.4Jikes2 minutes, 54 seconds
4Pentium M 1.8 Ghz7200RPM32-bit Ubuntu 7.04Sun JDK 5.0Jikes2 minutes, 7 seconds
Note that the change from JDK 1.4 to 5.0 on Ubuntu made the build
go 1.5x faster (which is significant), but less-so than on WinXP
5Intel Core 2 Duo T7800 2.6Ghz7200RPM32-bit Windows VistaSun JDK 5.0ECJ6 minutes, 22 seconds
6Intel Core 2 Duo T7800 2.6Ghz7200RPM32-bit Windows VistaSun JDK 5.0Jikes4 minutes, 38 seconds
7Intel Core 2 Duo T7800 2.6Ghz7200RPM32-bit Windows VistaSun JDK 6.0Jikes> 11 minutes!
Note that the performance disaster here *may* have something to do with some
kind of incompatibility Java 6 and Ant. That's my best guess, anyhow.
8Intel Core 2 Duo T7600 2.4Ghz7200RPM64-bit Ubuntu 7.10Sun JDK 5.0Jikes2 minutes, 23 seconds
9Intel Core 2 Duo T7600 2.4Ghz7200RPM64-bit Ubuntu 7.10Sun JDK 5.0ECJ3 minutes, 35 seconds

Conclusions for Fastest Performance:

  • Use JDK 5.0 and not 1.4 or 6.0 due to performance problems
  • Use Linux instead of Windows
    • 32-bit Linux is somehow a little faster than 64-bit Linux. Puzzling? (compare test#4 and #8). this leads me to believe that the only remaining bottleneck is the speed of the disk -- so we have to wait for bigger solid-state drives I guess
  • Use Jikes instead of ECJ
    • Note that Jikes doesn't support some of the new language features of JDK 5.0. Liferay source is based on JDK 1.4 so compiling with Jikes should be fine until we start taking advantage of some of these new language features

 

BTW, Many thanks to Michael Young for showing us all how to make the ECJ compiler work with Ant to build Liferay. Copying the ejc.jar file to Ant’s “lib” folder did the trick for me. See: LEP-4273

Liferay-ICEsoft Technology Partnership

Company Blogs August 8, 2007 By Neil Griffin Staff

On 7/23/2007, Liferay and ICEsoft announced a technology partnership aimed at making the ICEfaces component suite available to JSF portlets within Liferay Portal. Work towards this goal actually began back in late 2006, when ICEsoft decided to make changes to their framework in order to support JSR-168 portlet containers. Back on 12/14/2006, ICEsoft posted a message at the ICEfaces forums titled "Liferay Portal-ICEfaces Integration" in order to test the waters and make sure there was market demand for such a feature. To date, that post has received over 37,000 views, making it one of the most viewed posts on the entire ICEsoft forum site. Needless to say, this caught the attention of the folks at ICEsoft and Liferay, and technical dialogs between our companies began.

Also back in late 2006, I started a parallel post at the Liferay discussion forums that had the same title. I was particularly interested in having the ability to use the ICEfaces component suite within Liferay. Then it happened: a user named Michael Roth (redly2001) posted a sample ICEfaces portlet for use within Liferay Portal. I downloaded his example, and was able to get it working. Nevertheless, I ran into several framework-related and component-related problems. I did my best to correct them, and sent the fixes to ICEsoft.

Since then, we at Liferay have been working closely with the software engineers at ICEsoft in order to further increase compatibility. The first fruits of these talks resulted in several Liferay/ICEfaces demos that were demonstrated in both the Liferay and ICEsoft booths at JavaOne 2007. On 7/10/2007, ICEsoft announced version 1.6 of ICEfaces with compatibility for Liferay Portal 4.3.0. Liferay is currently working with ICEsoft towards ICEfaces 1.7, which will contain additional bug fixes and compatibility with Liferay 4.3.1.

Showing 41 - 43 of 43 results.
Items 20
of 3