Simplifying the Compatibility Matrix

Company Blogs June 22, 2018 By David Truong Staff

One of the initiatives our Quality Assurance Team has taken the past few years, has been to try and automate all their testing. This has resulted in testing all of our compatible environments in a similar fashion.  Thus, we no longer need to distinguish between Supported and Certified environments.
Starting with Liferay DXP 7.0, we will now list all our compatible environments together.  We hope this will make the decision to use Liferay DXP even easier.
Here is the new Compatibility Matrix.

Introducing Liferay Workspace

Company Blogs February 2, 2017 By David Truong Staff

A search for a better SDK

A little over a year ago, the Dev Tools Team began a new project hoping to fix the issues we encountered with the Plugins SDK. We had just finished modularizing our developer tools and were considering revamping the Plugins SDK to use all the new tools. This in itself would be a major improvement since we would no longer require a 300mb bundle just to use it. We decided, however, that it was time for a change.

Our first commits for Liferay Workspace started early last year (January 7, 2016 to be exact) and we've made a huge amount of progress since then. Many of you may have already created projects in Workspace since it's been in the wild for a while now. If you haven’t tried it yet, you can create one by first installing Blade CLI and then running blade init <my-project>. You should experiment with it a bit before proceeding to get some context because I won't be covering every aspect, but instead, just our design decisions.

Why we built Workspace the way we did?

Liferay Workspace is an opinionated, yet highly configurable multi-level project structure. It’s a combination of the strengths we found in the Plugins SDK and also what I found in other build tools such as Maven, Ruby on Rails, Gradle, and feedback from our users.

Having structure is good. Forcing structure is bad.

The most polarizing complaint with the Plugins SDK we heard was about the structure. It was laid out with preconfigured folders of hooks, layouttpl, portlets, themes, webs, etc. Some people love this structure since it was clear where to place their projects, but others hated it.

When developing Workspace, we decided that the structure was good for folks new to Liferay, but could be limiting for those who knew it well. Workspace comes with the following folders: configs, modules, themes, and wars. It’s clear what should go in each folder. If you don't like it, however, you can rename them, have multiple versions of the same types, or delete them.

Upgrading your SDK needs to be easy

The Plugins SDK was completely configured in the XML files. Since everything Liferay did was through the build.xml files, and we didn't provide any way for you to make changes easily, it meant upgrading your SDK was a chore.

While the original design of Liferay Workspace was to do everything in the build.gradle files, we quickly realized that it made upgrading a problem again. We rewrote everything into a plugins; issue solved. The biggest benefit from this is now we’re rapidly adding new features to Workspace and are constantly releasing new versions.

Project management should be automatic

One of the nice things with Ant was that any project with a build.xml was automatically included in the build. If you've used Gradle, you know that everything needs to be manually included in the settings.gradle file. I found this annoying coming from the Plugins SDK.

To combat this, we applied the Workspace Gradle plugin, which automatically adds projects as long as they have certain heuristics that let us determine they match the right folder. For example, modules should have a BND file, themes should have a Gulp file, WARs (which were a little harder to determine) should contain a source folder, etc. If they meet this criteria, they’re added to your project build.

Everyone should be on the same environment

The hardest thing about using the Plugins SDK was ensuring everyone was using the same thing. Bundles were configured individually. Everyone had a different version of Ant installed. Configurations were all over the place.

The best thing about using a Gradle project is that you don't need Gradle installed to use it. We took that concept further and allowed Workspace users to download a bundle and configure it all as part of the build process. This means that every developer used the same Liferay Portal version. This also means that if certain parts of the Portal needed to be configured in a similar fashion, the project could configure it for everyone. Moreover, this means that CI could more effectively join the build process because it was running the same things as everyone else.

You should decide your own build tools

One thing the Plugins SDK never gave you was a choice. You had to use Ant to build all your plugins using Ant even if the tool wasn’t the best tool for the job.

In Workspace, we decided to be more flexible with our tools. You can build your theme using Node or the build tool.  If you still need to use the Plugins SDK for legacy portlets, we’ve provided backwards compatibility.  And if you don’t want to use Gradle at all, we’ve provided a Maven version of Workspace. Surprise!

Providing a Maven Workspace was not part of our initial vision, but as we began to work out our Maven story, it made more and more sense. We finally published the archetype this week. If you would like to try it, execute

mvn archetype:generate -DarchetypeGroupId=com.liferay -DarchetypeArtifactId=com.liferay.project.templates.workspace -DarchetypeVersion=1.0.2

For documentation (sorry, the Maven Workspace docs are coming):


For an example of it in use (includes examples of Maven):

Please try out the different versions of Workspace. We are eager to hear your feedback.

The Missing Maven Elements

Company Blogs October 19, 2016 By David Truong Staff

I mentioned last time in The State of Maven Development, that we were missing a few items for our Maven users.

Well I have good news...

You can now build themes in Maven!

In pom.xml:




We’ve also published 18 maven archetypes with many more on the way!


  • com.liferay:com.liferay.project.templates.activator
  • com.liferay:com.liferay.project.templates.api
  • com.liferay:com.liferay.project.templates.content.targeting.rule
  • com.liferay:com.liferay.project.templates.content.targeting.tracking.action
  • com.liferay:com.liferay.project.templates.fragment
  • com.liferay:com.liferay.project.templates.mvc.portlet
  • com.liferay:com.liferay.project.templates.portlet
  • com.liferay:com.liferay.project.templates.portlet.configuration.icon
  • com.liferay:com.liferay.project.templates.portlet.provider
  • com.liferay:com.liferay.project.templates.portlet.toolbar.contributor
  • com.liferay:com.liferay.project.templates.service
  • com.liferay:com.liferay.project.templates.service.builder
  • com.liferay:com.liferay.project.templates.service.wrapper
  • com.liferay:com.liferay.project.templates.simulation.panel.entry
  • com.liferay:com.liferay.project.templates.template.context.contributor


Check back with us as we continue to work on documentation, more archetypes including one new one that should make starting your next project much easier.

The State of Maven Development in Liferay

Company Blogs July 5, 2016 By David Truong Staff

There's been some confusion over state of Maven support for Liferay. As the Product Manager for Developer Tools, I feel responsible for the confusion and felt the need to clear up any questions.

Will Liferay support Maven development for 6.1, 6.2, and 7.0?

Short answer, yes, most definitely!

In 6.1 and 6.2, we’ve been provided support through liferay-maven-support plugin. Support for this plugin will continue as long as we have users on 6.1 and 6.2. It is now in maintenence mode and will only receive critical bug fixes. We will be releasing fixes to 6.2.6-SNAPSHOT till the next release.

Maven Support in Liferay 7.0 is currently in a state of transition. I believe this is the cause of much of the confusion. Liferay 7.0 will no longer use liferay-maven-support plugin. In 7.0, different tasks will require different plugins. Service Builder has its own plugin; building SASS has its own plugin; etc.

Why did we decide to go this route?

The reason we decided to go in a different direction is because much of our tooling had previously resided inside portal-impl.jar. In 7.0, many of the tools were pulled out and live on their own. This gave us a new opportunity for a fresh start. We decided to turn each of these tools into its own Maven plugin. This means anytime there is a new release for any tooling, a new plugin will be released as they are bundled together.

It also allows us to decouple the archetypes from the plugin. Previously they were released together and it caused some issues when we wanted to release one without the other.

What are your future plans for Maven?

As I said for the maven-support-plugin is now in bug fix mode. No more new features will be added. We will continue fixing bugs. We also will not be releasing any new archetypes.

In 7.0, there are still some features missing that were available in maven-support-plugin. We are currently working on theme building. Archetypes are also being worked on right now. We are also working on a simple maven developer guide.

What is the current status? Is it possible to use Maven for a new project with Liferay 7?

For 6.1 and 6.2, nothing has changed. Continue to use the liferay-maven-support plugin.

For 7.0, you can absolutely use Maven to start your next project. If you want to see samples of the new plugins in use take a look at Maven Blade Samples. Archetypes aren’t ready yet so use the samples if you need a starting point. The only thing you can not do yet is to create a theme using only maven. We recommend you take a look at the new theme tools that leverage node.js if you can. It provides much more than a purely maven solution could ever provide.

Is there any documentation?

Not yet. As mentioned before, we are working on a Maven development guide. For now, I recommend you use Maven Blade Samples as a guide.

Liferay Portal 7.0 will be based on Java 8!

Company Blogs March 22, 2016 By David Truong Staff

We are pleased to announce that Liferay 7.0 will be moving to Java 8 dropping support for all previous versions of Java which are no longer supported by Oracle. The Liferay community can now enjoy the full benefits of Java 8 and all the libraries and tools that have moved to Java 8. You will also of course be able to make contributions to Liferay Portal using Java 8 in the near future.

What other benefits might you expect to see...

  • You will never see another java.lang.OutOfMemoryError: PermGen space
  • You will see us leveraging all the JDK 8 goodies in the near future. I expect our developers to take advantage of streams and lambdas right away. Functional/default interfaces and accumulators look like they will have some interesting use cases. Finally, I definitely would like us to take advantage of the new java.time package.
  • You will also see our developer tools moving to JDK 8. Liferay IDE and Developer Studio in particular will now be able to move to Eclipse Neon.

Some of you may be wondering why it took so long. Liferay 7.0 has been in development for over two years now and we are on the verge of our RC release. The answer is that we wanted to ensure all of our users had an upgrade path for their application server. Moving to Java 8 had been on our wish list since Oracle ended of support for Java 7 in April 2015, but unfortunately the app servers that we wanted to support wasn’t quite ready. We were prepared to support to stay on Java 7 if required because we were not willing to abandon any of our users. Fortunately, this is no longer an issue and we can all enjoy Liferay 7.0 and Java 8 together.

If you are not familiar with Java 8 yet, we recommend that you take a look at the "What’s new in JDK 8?" article from Oracle.

Update: You may have issues using Java 8 features with Spring 3.2.x that involves ASM/AspectJ as Java 8 support has only been added as best-effort support. We have upgraded our spring core to 4.1.9 so that we are fully compliant with Java 8.

Why Modularity Matters Part 1 - Dev Tools

Company Blogs July 24, 2015 By David Truong Staff

A little while back, I gave a presentation on a new command line tool that the tooling team was hoping to create to help ease development for Liferay. While we were able to get a working prototype for demonstration purposes we quickly realized that the project would never succeed with the current state of Liferay. The issue was that all of our tools required a bundle of Liferay. This was a huge limitation. One of our goals for this tool was that it would be small and lightweight. Being tied to a full Liferay 300mb+ bundle completely killed the idea.

Our team switched gears to a new goal, tools modularization. Liferay was already all gung ho in the idea of modularizing our core so we continually pushed the idea that part of this effort required pulling out all our tools. The first tool we tried was not pull anything out of core but instead was to create a new tool that wasn’t part of core. We implemented a java wrapper for libsass and switched out the ruby sass compiler. This decreased sass compiling to a tenth of the previous compile times. The great thing about this project is that this wrapper is just a standard jar and can be used in any java project that needs to compile sass.

It was clear that this was the right direction to go and six months later, just about every portal tool has now been extracted from the core including the holy grail of all Liferay tools Service Builder! While this is still a work in progress as some tools still haven’t completely broken free of all core dependencies we are already reaping many benefits from this new found freedom.

One immediate benefit that you guys will see is better support! I remember while I was on a consulting project many years back, we had an issue where our custom service builder plugins didn't have any transactions. It turned out to be a small bug in Service Builder but we had to wait 3 months until the next release of Liferay before we could actually fix the issue. Granted our patching and releases are much quicker these days but you are still at the mercy of a release for current versions of Liferay Portal. But with Liferay 7.0, if we discover a new bug in Service Builder you no longer have to wait till the next release of Liferay to get a bug fix. We can push out a fix to our repo and you guys can grab the new jar right away. It also means new features in tooling aren’t tied to portal releases. If one day a native java implementation of a sass compiler comes out, you can expect a new CSSBuilder that can take advantage right away.

A second benefit we've seen now that most of our tools are available as modules is this has made it easier to create byte-sized projects for building new plugins for Liferay 7.0, namely OSGi bundles to take advantage of the improved modular framework (OSGi) running inside Liferay 7.0. The first part of this effort was to create a "Liferay cookbook" repository to demonstrate how to build "Liferay 7.0 modules using OSGi”. We have cataloged many examples of Liferay 7.0 integration points using various build systems (maven, gradle, bndtools). The plan is for this repository to contain more than 120 integration point examples.

The next part of our "tools modularization" process is with Liferay IDE our official Eclipse plugins. This project Liferay IDE has been around for over five years, but all of the tools have been only available as eclipse plugins and thus only executable as a part of an Eclipse IDE/Workspace. However, along the theme of "modularization" we have decided that going forward we are going to build "tools" that will end up in the IDE in a reusable and more modular way. As an example for Liferay 7.0 we are building a "Project Migrator" tool that will help Liferay developers migrate their 6.2 plugin projects to 7.0. In the past this tool would have only been built as a part of Liferay IDE Eclipse plugins, but now we will build them as a reusable OSGi bundle that can be used either in Eclipse or in other applications/use-cases.

And finally one last benefit of modularization has been that we've retrofitted all of our SDK's to use these tools. Which means we're very close to having all of our SDK's completely independent of a bundle to function and all of our SDK's all call the same code base through their plugins. This has allowed us to create a new SDK based on Gradle. It’s already being bundled with our current Plugins SDK if you want to give it a test run though it’s also still a work in progress.

Now back to where we started, the command-line tool. One thing that we are adding to the repo is a new "CLI' called "blade". It will provide a command-line based way to execute these new modular tools like creating, migrating, and deploy Liferay 7.0 modules. It will also leverage the blade repo for stubbing out projects. It's in the very early stages and still much work needs to be done but we're extremely excited that we can finally provide a tool we've envisioned many years ago. Developing for Liferay 7.0 should be easier and more flexible than ever allowing you to pick and choose which way is your preferred method of developing.

Checkout out the repos:

Liferay Portal -
Sass Compiler (libsass) -
Service Builder -

The next time we discuss why modularity matters, we’ll focus on our compatibility matrix.

Once Upon a Time

Company Blogs April 6, 2015 By David Truong Staff

This is a story about two sisters, Portal and Platform.  Their father, Brian Chan was a strict and careful man.  He knew his daughters could help the world so he made sure they were always very tidy and followed all the rules and all the standards.  He opened up his home and let anyone visit his daughters for he had nothing to hide.
The older sister Portal was beautiful and had many talents.  It was clear from the beginning that she would grow up to be a star.  She dressed herself up with beautiful themes and expressed herself with web content, blogs, and message boards.  Soon she added friends and helped them collaborate on different projects.  And so it was… the world started taking notice and companies from all over the world began taking notice of her and asking for her help.
Her younger sister Platform was quiet and shy.  She stood in the background and helped her older sister out by scheduling tasks and making sure all the services that were required completed properly.  She kept track of all the data even if they spread out over multiple places.  And her secret weapon was the tools she kept in her bag.  She had tons of utils to help her compile code and generate new services.  She enjoyed this role and it suited her.  You see this job was a very demanding job and after ten years, Platform began taking on much weight and began to get heavy.  She was still efficient at her existing jobs but asking her to do anything new was incredibly difficult and Portal was starting to get frustrated.
One day their Uncle Ray came to visit and told Platform you know you don’t have to struggle with all this weight.  I know a way to make you lighter and more agile.  It’s called OSGi and many have used it to slim down when they were in a similar position you are in.  Let me talk to you father about it.
Uncle Ray went to their father and pleaded with him and after two years was finally given permission to help Platform lose her weight.  He brought along his friend and fellow trainer Miguel and they devised a strenuous program for Platform.  It would require her to give up many of the tools she was used to carrying.  It would require that she become more of a manager for portal instead of doing everything herself.
So she worked to hard and gave up many services that she used to do and instead created contracts and let others provide the service.  And those tools that she thought made her special she realized had gotten incredibly dull.  She felt so awful that she wasn’t able to give them the attention they deserved.  she felt confident others could help her keep them sharp and new.  And as all this happened… she realized she was stepping out of the view of her sister.  She was becoming her own person.  She wasn’t just useful to her sister.  She was finally becoming the person her father saw she could be.  

Happy Pi Day and Happy 10 Year Anniversary!

Company Blogs March 14, 2015 By David Truong Staff

Happy Pi Day everyone!

You guys should take a look at this site which makes some cool art from the number π.   Also reminds me also that I have two raspberry pi's that need some attention.  Anyone got any suggestions for them?

Today is also my ten year anniversary with Liferay!  Wow… I’ve spent a whole decade working for a company! This means I’ve put in 10000 hours and you can now consider me an expert on Liferay!  The company is vastly different from the one from ten years ago.  My mother didn’t even consider Liferay a company at the time and was hoping I find a job with a real company like IBM, Microsoft, or Oracle.  I think though that we've really grown as a company over the last decade.

Here's ten photos over the last ten years for you to see yourself:

Photo of the earliest employees of Liferay and me 20 lbs lighter!

An early release, Liferay Portal 3.6.1.

Before there were symposiums, we had a Liferay PUG (Portal User Group).

Original banner ads!

Getting our hair cut by students from a vocational school in Tumen.  One of our first forays into philantrophy.

Remember when I built my wedding website on Liferay?

First time in Madrid.

Liferay 2013 Retreat

North American Symposium 2014

This language is way harder than Java!  Hello world.  Welcome Kelsey.

If you've made it this far... I only have one last thing to share.  Becoming a father has taught me that you must show off your baby at every possible moment you can. One significant change that has happened within the last few years of Liferay was my move into a Product Manager.  It's sort of a fatherly role so I need to really do my best showing off my baby.  So over the next couple posts I will be showing off different parts of my Liferay "baby".  Her name is Platform.

Custom Finder for Portal Entities in a Plugin

Company Blogs June 22, 2012 By David Truong Staff

Sometimes you need to write a custom finder for a table that belongs to core. In my case it was JournalArticle.  My client wanted to avoid using the ext-plugin as much as possible so I had to try to figure out a way to do it within a portlet plugin.

I tried to use dynamic queries as a solution but it turned out to be inadequate because I was unable to group by (I wanted to get the latest articles with a certain structureId).

I needed a custom finder but for awhile I thought this was impossible because you needed to load the Impl of a model during the query which is inaccessible since it is part of portal-impl.  But my experimentation with dynamic queries was not in vain because I figured... if dynamic queries can figure out a way to load the impl class I could probably do the same.

So here is the class I wrote.

It consists of two basic methods:

public static Class getImplClass(Class clazz, ClassLoader classLoader) {
    if (!clazz.getName().endsWith("Impl")) {
        String implClassName = clazz.getPackage().getName() + ".impl." + 
            clazz.getSimpleName() + "Impl";

       	clazz = _classMap.get(implClassName);

       	if (clazz == null) {    
            try {
               			if (classLoader == null) {   
                    Thread currentThread = Thread.currentThread();

                    classLoader = currentThread.getContextClassLoader(); 

                clazz = classLoader.loadClass(implClassName); 
               _classMap.put(implClassName, clazz); 
            catch (Exception e) {
                _log.error("Unable find model " + implClassName, e);
    return clazz;
public static Session openPortalSession() throws ORMException {
    return sessionFactory.openSession();	

private static Log _log = LogFactoryUtil.getLog(CustomFinderHelperUtil.class);

private static Map> _classMap = new HashMap>();
private static SessionFactory sessionFactory =

So basically in my customFinder instead of doing

session = openSession();

I did

session = CustomFinderHelperUtil.openPortalSession();

and instead of doing

q.addEntity("JournalArticle",  JournalArticleImpl.class));

I did

q.addEntity("JournalArticle", CustomFinderHelperUtil.getImplClass(
                JournalArticle.class, true));

(I created a extra method that took a boolean to use the portalClassLoader, you can load it using PortalClassLoaderUtil.getPortalClassLoader())

Hopefully this helps some you guys out.


node.js with Liferay 6.1

Company Blogs March 7, 2012 By David Truong Staff

Wow, it's been a while since I last posted.  Liferay 6.1 EE has just been released and it's changed so much!  I decided to build a node.js app that calls Liferay using the improved JSON web services.  Really, I think this could work just as easily with 6.0 but whatever.  The project currently grabs the layouts of the Guest community and displays the portlets as widgets and using bootstrap for default styling.  

There's no reason for this project but I did it just to do it so it's more of a hacked together project but here it is for anyone interested in improving it or playing with it:

You will need a liferay 6.1 server running on 8080 using

Potential use cases:

  • Write a mobile site
  • Write a new frontend 
  • Integrate Liferay with another node app using this as an example

Things that might be fun to improve:

  • Grabbing the portlet data and writing our own front end
  • Adding user authentication
  • Add token authentication to Liferay so I don't have to hard code a user in my code.


That's it!  Hope my next post comes a lot quicker than this one.

Take care

Five years and already a liferay of memories

Company Blogs March 15, 2010 By David Truong Staff

This month marks the fifth year, I've been with this company.  A quick warning: I'll be sharing some personal thoughts so if you are looking for something more technical check out Ed Shin's post for that (we started at the same time, so it is his five year anniversay also).

Liferay was my first real job.  I was 22 when I accepted my Liferay position and they gave me 3 days to move to LA.  It was the scariest decision I had made in my life but it has turned out to be one of the most rewarding.

I remember the first day I arrived thousands of miles away from home (I'm from Chicago), I walked into 6 guys in a tiny cubicle.  On that day I connected with my ancestors a little bit more as I tasted what they must have went through working in Chinese sweat shops.  That though was not the biggest shock of the night. 

I was told that they would provide room and board when I went to LA.  They told me a hotel or some alternative would be provided.  The alternative was provided.  The alternative was Brian Kim's friend's apartment floor.  Yes, Brian Kim's FRIEND's apartment floor!  This floor was to be shared by Brian Kim, Ed Shin, and me...  If you are wondering how I made it past that first day... I've wondered that same question many many times. 

I can do all things through Him who gives me strength.

Things actually got worse.  A few days later, I discovered BKim's friend was a trader and went to sleep at 10 pm and work up at 5am.  The bathroom was conviently located in his bedroom.  It was 10:30pm.  I needed to use the bathroom but I was afraid to wake up his friend so I just held it.... until the morning.  I never fell asleep that night because I was afraid I would accidently pee in the queen size aerobed I was sharing with my coworker Ed who I had met yesterday. 

"Have I not commanded you?  Be strong and courageous.  Do not be terrified; do not be discouraged, for the Lord your God will be with you wherever you go."

Things actually got worse.  So I let Brian Chan and Brian Kim know that I was uncomfortable living at BKim's friend's apartment floor.  Ming-Gih one of the other new hires let me know I could stay with him.  He lived at his friend, Wilson (who eventually joined the company)'s sublet room floor.  It wasn't much of an upgrade but at least the room was private, the bathroom wasn't located in some strangers room, and because the friend was going out of town, I could sleep on the floor by myself.  We stayed there two days before the police came and informed us that Ming Gih's windshield got smashed over night.  Wilson's landlord thought we were part of a gang so we left in search of a new home where we could rest our feet.

"For I know the plans I have for you," declares the Lord, "plans to prosper you and not to harm you, plans to give you hope and a future."

The next day Mike Young graciously volunteered his home and took care of us the rest of the weekend.  That was my first week in LA.  Honestly at the time, I was ready to go home already, but I'm glad I didn't.  Looking back at it now, I laugh and realized it made the rest of the journey that much more memorable.  That was just the beginning and definitely things could only get better from here... right?

My New Obsession: SEO and Liferay

Company Blogs February 3, 2010 By David Truong Staff

So BChan should have never given me a server.  Since making my wedding site, I've been exploring different things about websites outside the scope of portlet development.

This includes:

  • Setting up a full web server (not just running startup.bat)
  • Business (if you could call what I'm doing business) Requirements
  • Advertising (adsense, etc.)
  • SEO

The last one has become somewhat of an obsession for me.  It seems silly to want to have Google/Yahoo/Bing list your website because after all who is going to want to search for my wedding website, but there is something truly satisfying knowing that you are ranked in the single digitals for a search query.  I am current ranked 3 for "david and winnie" because there's some dude named David Winnie... arg!

Well anyway's I've come to let you guys know my discoveries (that is if you care at all about SEO) so you don't make the same mistakes I did.

1.  If you can live with url sessions you should immediately disable it.

This is how: in

Most of us don't need it since most of us require cookies for our sites || (don't require cookies && url sessions) I would actually recommend everyone do this.  Here's an article that explains further why they suck and also shows you an alternative way to remove them if you aren't lucky enough to use liferay.

Why?  Because googlebot and all the other crawlers don't support cookies so the url's to your site all end up with ;jsessionid=12356yourseoisscrewed5950 and you end up with duplicate urls because ;jsessionid=12356yourseoisscrewed5950 != ;jsessionid=6079messedupseo459056.

2. If you need them, you need to set up mod_rewrites for them immediately

I can't give a full answer for this one since I've never done it.  But I did read alot of stuff so here are some suggestions...

Make a RewriteCond for Googlebot, MSNBot and all the other ones you can think of.

Then a RewriteRule that removes the jsessionid...

I'm not sure the what the answer is really... if you know leave a comment.

3.  If you've messed up and trying to recover from your mistake (same boat as me)

First read this article.  Then do what they say =).  It took me awhile to figure it out since I didn't know apache that well because I was trying to do everything in http.conf.  I had to do them in my virtual hosts conf file before it worked because I have my server running another site (maybe I can explain another day what I learned from that site).

You are basically writing a mod_rewrite that tells the crawlers that all urls with jsessionid's appended to them have moved and they will take them off the list of urls for your site.  This is good because you won't have duplicate urls which makes them think you have duplicate content.

So there you go...

If someone can tell me how to use robots.txt for virtual hosts.. or even setting it for just one server since all my sites will use the same robot.txt   And I did read the wiki... just need more explanations =)

My Wedding Website

Company Blogs January 21, 2010 By David Truong Staff

Hey guys,

So I promised I would put up a link and so here it is:

Here were a few things I learned...

1) Weddings are really expensive... I should create a donate to my wedding portlet and let anyone send money to my paypal =P

2) Props to you if you are good at photoshop.  The pictures took me a long time to do and they don't even look great.

3) My site doesn't work in IE and I don't care

4) MP3 player's don't really work well for websites unless it's flash.

First a lot of people don't like them but my soon to be wife does so sucks to be them... 

Next reloading a page causes a song to start over each time... I spent seriously 2 weeks trying to figure out a good solution.  If you have a flash site, this isn't a problem but unfortunately I don't know how to code in flash/action script.  I didn't really want to use frames and in all honesty... I wasn't sure how to do frames in Liferay...  I tried a flash mp3 player with autoresume but it didn't seem to work in Firefox and I do care about that... so I decided on making the whole content part (everything under then nav and above the footer) refresh with ajax.

AJAXNav = {
	init: function(params) {	
		var layouts = jQuery(params.className);
	changeNavURLs: function(layouts) {
		var layout;
			function() {
				layout = jQuery(this);
				var friendlyURL = layout.attr("url").replace("/", "#");
				layout.attr("href", friendlyURL);
					function() {
						var a = jQuery(this);
						var p = a.parent();
						var plid = a.attr("plid");
						var friendlyURL = a.attr("url").replace("/", "");
						//var url = document.location.hash;
						 window.location.hash = friendlyURL;//url;
							"/c/portal/url?p_l_id=" + plid,
							function(html) {
								var layouts = jQuery(".sub-nav-item");
								if (layouts.length > 0) {
									console.log("processing .sub-nav-item");

That was the code I wrote in javascript.  If you noticed the url was /c/portal/url which basically hit a custom action I made that spit back portlet.jsp.  It worked actually fairly well actually but I had some other issues. 

The back button stopped working so I had to do some funny things with the url adding anchors (i.e. #home) to signal the page changed.

I couldn't get the AJAXNav to play nice with the twitter widget... and unfortunately that was just cut and paste from Twitter so I can't modify that code.  I actually wrote my own twitter portlet that parsed my rss feed so I could still switch to that but I'm not sure all that work I did was worth the effort anyways.

In the end I think I will just make the mp3 player into a popup so you can leave it running if you like or close it if it bugs you.

4) Now that you all discovered I am not a cartoon ninja, I have decided I must put up a real image of myself soon for my avatar (which I liked as a movie).

Love, Marriage, and Liferay?

Company Blogs December 23, 2009 By David Truong Staff

It's been awhile since I last posted a blog.  It's not like I had a bunch of avid readers; in fact I would be surprised if I even had one.  But nevertheless a lot has happened which has kept me away.  The most notable thing is that I got engaged and I am now in the process of getting married.

Being the prideful web programmer that I am, I decided I had to build my own website.  I was thinking which direction I could go.  I could have used Word Press.  It's easy and honestly it's a pretty darn good product.  In retrospect, it may have been the better choice but I decided to go with Liferay.  I used the EE version since I can generate my own keys but I could just have easily gone for the latest 5.2.x CE.  Both are excellent solutions.

I had to eat my own dog food I guess but right off the bat I want to tell you, it tastes pretty darn good.  I only brought up that maybe Word Press was a better solution because of a few things, cost and how simple my website was.  I'll let you guys know my experiences of using Liferay for my wedding site but if some of you guys want to stop now, here is the bottom line.  Liferay isn't the best choice for personal websites, but I can see why companies use Liferay and fall in love.  It is the best open source portal in the market (fact) and maybe the best portal period (maybe I am biased).

First thing first I go over the negatives of Liferay for my wedding website.

There were too many features, too many options.  In real life this wasn't a negative but because my website was so simple I had to decide between all the different options.  Should I go with cms, portlets, leverage existing Liferay portlets?  The options were endless.  It was a good and a bad thing.

Second and last negative.  This is a biggie.  I couldn't find a cheap place to host my site.  Java hosting is expensive!!!  Not quite as much as getting married but it's not like php.  I could have done tomcat hosting, but it was pretty complicated to get it working right and even harder to get it working with my plugins also since I didn't want to build anything in the ext.  I tried to get a vm but they were usually around 50 dollars a month!  When you're saving any way you can for the wedding of your dreams, there is no way to justify that. I was just going to have to swallow my pride and go to and use one of their templates for my site.   Luckily Liferay, loves me and gave me my own private vm so I didn't have to resort to that =).

Ok now for the good things.

It's so easy to develope for Liferay.  The plugins have made my life as a liferay consultant so easy.  I built all my portlets and theme in a matter of a few days.  I'm a Liferay expert of course so it made things faster but still Liferay is simply a fantastic tool to use to build a professional website.  We could really change our product and call it Liferay Framework and I doubt anyone could disagree.

The CMS is so much better now.  I am one of the first employees in Liferay so I started using Liferay from its earliest versions.  I remember on one project for a non-profit we built much of their content on our CMS.  It was a nightmare.  We built some of their content with portlets because the CMS wasn't advanced enough to handle what we needed it to.  If we did the same project today, I doubt we would need portlets and I think I could have done the entire project myself instead of needing a 3 man team.  It has gotten that easy and that good.

There are a lot of features that are really made my life easier.  I used remote publish from my laptop to publish my website to my vm.  If I didn't want to do that I could have just manually exported my communtier to a lar and then import it back.  I could create different communities and host other sites if I wanted to.  And Liferay is almost easy enough that I might be able to ask my fiancee to do some stuff.

Using Liferay did allow me to do somethings Word Press wouldn't have allowed for (not that I know of at least).  I was able to build a guest list portlet where I could input all my guest and have them register what foods they want.  I can later export this to excel if I feel like doing that and I guess that's the beauty of using Liferay.  I feel like I have the power to do anything I want as long as I want to put some hours into it.

* Hopefully I can update this post with a link as I'm still in the process of getting all the content written =).

Idealist vs. Pragmatists

Company Blogs April 3, 2008 By David Truong Staff

I read an interesting article today.  You should probably read it first to understand my thoughts but I’ll summarize since most of you aren’t gonna read it and it’s a bit long anyways…  It’s talking about the decision Microsoft has to make with IE8.  The problem is that IE7 and below are all bad browsers because by default they are in quirks mode (it means it renders the page funny… ie style).  The dev team now has to decide if they want to go the same route or switch to standards mode which is what firefox, opera, safari does… and I know most of you are thinking oh of course switch to standards mode… but in reality the solution isn’t that simple because that mean’s millions of pages designed for IE (and IE8 is still IE) will now be broken.  The question is do you piss off the people who will be building the stuff for your product (developers) or do you piss off the people who’ve been supporting you (customers).

I thought this article was interesting not because I care what decision Microsoft will ultimately make…  but I think Liferay is finding themselves in this position with the release of 5.0.  We’ve already made decisions (java5) that will cause us to lose some past customers… (hopefully that will be offset by new customers that will pick us because of the decision).  I think we are at a crucial time where a lot of us are hoping to make even more drastic decisions that will further kill our backwards compatibility… but offer us in return the opportunity to make Liferay the best product it can be… like using Expandos or tighter integration with spring/hibernate or whatever…  we shouldn’t be tied down to our past anymore if we want to make a better future product.  But that’s never the path we take… (except java 5 which we were forced to do)… we always build for a way to be backwards compatible.  The key word here is TO BE.  We are not always backwards compatible by default (Neil found an issue with existing url's and the new JSR-286) which is why I of all people found this article interesting.

Everyone in Liferay is put into one of two sides:  There are the core developers and then support/consultants.  Yeah everyone does a little of both but primarily that is their job… anyways it’s hard as a consultant sometimes that the core team makes 80% of the decisions about the product when we do 80% of the (money-generating) work… I’m not being bitter like I think that’s the right way to go about it… just hard in that we have to figure out stuff like Neil’s URL issue without always knowing why it's happened (I've done every upgrade since 3.2 to the next version.. so I know how you're feeling Neil!).  So this has been complained about a lot before to the core team (that knowledge must be transferred better)… and it’s not really the point… but rather new insight because recently I went to China with Brian (Chan) and Nate. I spent some time working on core and spent time seeing people working on core.  And the improvements they are planning to make or are in the process of making is very exciting.  So exciting that I think older companies might be willing to pay more money to have these new features even if they have to abandon some previous work.

Anyways, if there’s only one thing you read about this post… it’s this: the article I read was really about Idealists (in our company it would be people like Nate who preach standards, standards standards… if they don’t want to support standards then screw them.. we want to make Liferay the product AWESOME) vs. pragmatists (in our company it would be Ed Chung… standards are good.. but they can’t get in the way of our ultimate goal… not to make Liferay product better… but to make more money for the company).   The article ended with this: “You see? No right answer. As usual, the idealists are 100% right in principle and, as usual, the pragmatists are right in practice.“  I realized that as a company, Liferay is constantly walking a fine line between the two, fighting to find that balance… and I think it’s also the reason Liferay hasn’t failed like so many other open source projects.


Blog Improvements!

Company Blogs October 29, 2007 By David Truong Staff

Our blogs has finally gotten a second look and I'm glad.  Blogs should be improved tredmendously and already I see people commenting on people's blogs.  Hopefully the response to blogs will be as positive as the ones we received for message boards and mail.  When Liferay decides to use our own products we really put in a lot of effort to make it a very good product so we should continue to see major improvements to blogs.  Already Brian Chan has told me we've just checked in a new commenting system that makes it way more usable and this weekend i finished writing tag libraries (which aren't restricted to blogs btw)  to add digg, delicious, furl, newsvine, technorati, blinklist, and reddit.  So soon you will be able to digg this article =).  I need to add a few more.. boingboing, fark, stumbleupon, magnolia...  but blogs is looking good... Next we should move all our docs into our own wiki so we are forced to rewrite it and make it awesome (Jorge already started)!


Company Blogs October 24, 2007 By David Truong Staff

"I took a look at jboss portal and concluded that nothing is wrong with liferay, haha" - bui

smart guy haha

Things Liferay should consider changing ASAP!!!!

Company Blogs October 23, 2007 By David Truong Staff

  • more scaffolding ant tasks that will fill in all those annoying xmls for us and create a basic portlet action
  • better urls... i know why we have the ones we have and why we need them but we need to figure out a way to simplify them even more... as the home page without any apache url rewrites would be lovely (virtual hosts)
  • better blog!  guest cant even comment yet.. you need to dig in to the entry before you can comment
  • explore the possibilities of scripting languages more.... i think we support most of them now.. now lets try building something significant with them to see how good it is.
  • more unit tests even though they dont make sense alot of times so people will stop complaining
  • better documentation for simple stuff... how to override a jsp..  add a colorscheme.. differences between portal and portlet pages... small things that seem trivial to liferay experts but would help a newb alot.. and we actually have some of them but people cant find them so it means wherever we are putting them is too hard to find.
  • pull out all portlets to deployable wars... which will be tough since alot of portlets depend on each other.. which means those things need to be pulled out or those portlets need to be bundled together..
  • redo permissions ui more..  its supposedly alittle better now..  but still.. it kinda sucks
  • add narrow and wide views back to columns so we can define how portlets should look if its in a narrow or wide view.. it used to be in 3.6 but we thought we didnt need it.. but we were wrong it turned out to be useful.. a little at least
  • load javascript better smarter or smaller... one of those.. nates been working on it and its making progress
  • sessionless stuff is super buggy..  it looks promising.. we should improve it...
  • get someone to design a theme thats crazy looking cause we havent seen one yet...EDIT..the aqua theme was pretty crazy...a new one like that!
  • build a text to image filter and also a gradient filter...  to help the themes out.
  • and last but not least make my blog public because i must be heard!

Lotus vs. Excel

Company Blogs September 26, 2007 By David Truong Staff

A recent blog made a comparison between Lotus 123 and Microsoft Excel.  I found it interesting because our CSA Brian Chan often uses this example when describing Liferay's company strategy.  And while I already posted on how I felt our product has become somewhat bloated, the article reminds me all the more, that it definitely is better to have too many features rather than too few.

But another thing i found interesting was the point he made about javascript sizes.  If you've been following our discussion forums, you would have noticed that one of the most talked about topic is javascript sizes.  If what this guy writes is true, maybe our javascript size isn't an issue at all (which i admit is quite large at the moment).  If yesterday I felt we were building Liferay backwards, today I feel like Liferay is being built for the future .




Built Backwards?

Company Blogs September 24, 2007 By David Truong Staff

I've noticed in alot of our projects, we've been ripping alot of the "features" from Liferay and it got me thinking...  Maybe we built Liferay backwards and judging by the new features we've been implementing (plugin system most notably), I'm almost certain we did.  The portal might be the most featured packed portal out in the market but unfornately, most projects we've been doing has used only a handful of the features at any given time and rarely needs or even want the other features included.  While it's definitely great that we have so many features, we've made a grave error in not making  these components optional.  Instead of becoming a more flexible product we actually became the very opposite.  Our product has become bloated.  I'm glad the core dev team has seen the problem and moved quickly on correcting it.  I've been playing around with the new plugin system and it just seems to open a door to so many different possibilities.  Maybe one day we will finally see a Liferay Lite (Literay?!?) and everything is optional.  That would definitely make Liferay portal truly flexible and perfect for just about any site.  I guess for now having a portal with too many features is (WAY) better than having a portal without any features.

Showing 20 results.
Items 20
of 1