Category: Liferay

A powerful and popular open source portal

October 1, 2009

Can GateIn, the new JBoss Portal/eXo Portal combination, outshine Liferay?

I know I’m way behind on this. I’m kind of surprised at how little attention it has received. Maybe I need to refresh my portal-based news feeds. In any case, earlier this Summer, JBoss and eXo announced they would be combining the JBoss Portlet Container with eXo Portal to create a new project called GateIn. Other than the similarity between the concepts “portal” and “gate” I’m not sure what they are going for with the name, but don’t let that throw you off. To get an idea of what it’s about, check out the demo.

Most of our clients looking for open source Java portals have been interested in either JBoss Portal or Liferay. In choosing between the two, one consideration was that, historically, JBoss Portal has been less about out-of-the-box portlets and flashy UI and more about providing a presentation framework. Clients developing solutions that were really 100% custom apps with a portal-like interface leaned toward JBoss Portal (especially if they were already a JBoss shop). Clients looking for more of an “instant community” with ease-of-use on the configuration side and a large number of out-of-the-box portlets leaned more toward Liferay. GateIn appears to be a big step forward for JBoss Portal in terms of the user experience for portal administration and makes JBoss Portal about more than just a framework for presentation services.

Beyond requiring a great user experience for both end users (site consumers) and portal administrators (content managers), portals must also have a fast and intuitive development model. I think this is especially true lately as lighter-weight presentation frameworks have become more popular. As the difference in capabilities between portal and non-portal presentation frameworks becomes less and less, portals can’t afford to offer a soul-sucking development experience.

I haven’t spent any time customizing GateIn so I can’t comment on the developer experience. What I do know is that when you move from developing code using lightweight frameworks like Drupal or Django to Java portal servers like Liferay, you feel the increased complexity immediately. Anti-Java-ites will say that a lot of the complexity in the development experience is there because it’s Java and it will always be that way. I don’t think that’s true–look at frameworks like Grails and Wicket.

The point is, for GateIn to be a serious challenger to Liferay, they’ll need to provide not only the eye candy on the front-end, but also a developer experience that approaches the productivity level we can get with non-portal frameworks. If they can do that, they have a chance against Liferay. Of course even if they manage to do that, they are still up against the “Do we really need a portal server to do this?” undercurrent that threatens both projects. But that’s another blog post.

August 31, 2009

Review: Liferay Portal 5.2 Systems Development, by Jonas X. Yuan

I’ve just finished Jonas X. Yuan’s book, Liferay Portal 5.2 Systems Development and I thought I’d share a few thoughts.

First, I should probably get this out of the way: Jonas works for Cignex, which, from time to time, competes for business with my firm, Optaros. Okay, back to the book…

My overall impression of this book is that it essentially documents the work Jonas and his team did for one of their clients. While it is great that their project was broad enough to generate enough material to be compiled into a book, I felt like I was reading “here’s what we did on our project” instead of “let me teach you how to do Liferay development”.

When I read a technical book, I like to read about concepts and how I might apply those in different situations, and then dive into a realistic application of that concept. This book definitely covers realistic examples–the screenshots are lifted right out of the solution Jonas and his team built for their client. And I like that the example is fairly consistent throughout the book. But I found it very light on context and concepts. That left me feeling a bit disoriented as Jonas jumped from detail to detail with very little being done to set the scene. A simple explanation of “Why are we doing this?” would have been a big help.

Another thing that made this a tough read for me is that there are many grammatical issues with the text. If this were in one or two places, you could rightly accuse me of being a hard-grading Grandson of an English teacher (which I am). Unfortunately the problem isn’t limited to one or two places–there’s one on nearly every page. I don’t blame Jonas for this, I blame the editor. Is the pressure to publish on schedule so great that there is no time to perform even rudimentary grammar checks for things like missing articles?

If you can get past the style, there are good takeaways in the book. You’ll learn:

The difference between building customizations in ext versus plugins
How to use ServiceBuilder
How to build portlets using Struts and Tiles
How to extend the Journal CMS with structures and templates
How to build and customize themes and layout templates

There’s a chapter on Liferay’s Social Office and how it works behind the scenes, including details on Inter-Portlet Communication. Jonas has also included a chapter on moving content between multiple environments (Staging/Production) which is an area where portals are often less than optimal.

There is a lot of code included in the book and available for download. Several of the code snippets in the book need to be debugged before they will run properly, but most are easily worked through. The book suggests working with the Liferay source from HEAD, but I had to use the 5.2.3 tag to get the ServiceBuilder stuff to work correctly.

While this book isn’t for everyone, I’m glad Jonas wrote it. Liferay is a complex piece of software and the community needs all the documentation help it can get.

April 20, 2009

Alfresco User Interface: What are my options?

People often need to build a custom user interface on top of the Alfresco repository and I see a lot of people asking general questions about how to do it. There are lots of options to consider. Here are four options for creating a user interface on top of Alfresco, at a high level:

Option 1: Use your favorite programming language and/or framework to talk to Alfresco via REST or Web Services. PHP? Python? Java? Flex? Whatever, it’s up to you. The REST API is nice because if you can’t find a URL that does what you need it to out-of-the-box, you can always roll-your-own with the web script framework. This option offers the most flexibility and creative freedom, but of course you might end up building constructs or components that you may have gotten “for free” from a higher-level framework. Optaros‘ streamlined web client, DoCASU, built on Ext-JS, is one freely-available example of a custom UI on top of Alfresco but there are others.

Option 2: Use Alfresco’s Surf framework. Alfresco’s Surf framework is just that–it’s a framework. Don’t confuse it with Alfresco Share which is a team-centric collaboration client built on top of Surf. And, don’t assume that just because a piece of functionality is in Share it is available to you in the lower-level Surf framework. You may have to do some extra work to get some of the cool stuff in Share to work in your pure Surf app. Also realize that Surf is brand new and still maturing. You’ll be quickly disappointed if you hold it to the same standard as a more widely-used, well-established framework like Seam or Django. Surf is a good option for quick, Alfresco-centric solutions, especially if you think you might want to leverage Alfresco’s browser-based site assembly tool, Web Studio, at some point in the future. (See Do-it-yourself Alfresco Surf Code Camp).

Option 3: Customize the Alfresco “Explorer” web client. There are varying degrees to which you can customize the web client. On one end of the spectrum you’ve got Freemarker “presentation templates” followed closely by XML configuration. On the other end of the spectrum you’ve got more elaborate enhancements you can make using JavaServer Faces (JSF). Customizing the Alfresco Explorer web client should only be considered if you can keep your enhancements to an absolute minimum because:

Alfresco is moving away from JSF in favor of Surf-based clients. The Explorer client will continue to be around, but I wouldn’t expect major efforts to be focused on that client going forward.
JSF-based customizations of the web client can be time-consuming and potentially complex, particularly if you are new to JSF.
For most solutions, you’ll get more customer satisfaction bang out of your coding buck by building a purpose-built, eye-catching, UI designed with your specific use cases in mind than you will by starting with the general-purpose web client and extending from there.

Option 4: Use a portal, community, or WCM platform. This includes PHP-based projects like Drupal (Drupal CMIS Screencast) or Joomla as well as Java-based projects like Liferay and JBoss Portal. This is a good option if you have requirements that match up well with the built-in (or easily added-on) capabilities of those platforms.

It’s worth talking about Java portal servers specifically. I think people are struggling a bit to find The Best Way to integrate Alfresco with a portal. Of course there probably is no single approach that will fit every situation but I think Alfresco (with help from the community) could do more to provide best practices.

Here are the options you have when integrating with a portal:

Portal Option 1: Configure Alfresco to be the replacement JSR-170 repository for the portal. This option seems like more trouble than it is worth. If all you need is what you can get out of JSR-170, you might as well use the already-integrated Jackrabbit repository that most open source portals ship with these days unless you have good reasons not to. I’m open to having my mind changed on this one, but it seems like if you want to use Alfresco and a portal, you’ve got bigger plans that are probably going to require custom portlets anyway.

Portal Option 2: Run Alfresco and the portal in the same JVM (post). This is NOT recommended if you need to scale beyond a small departmental solution and, really, I think with the de-coupling of the web script engine we should consider this one deprecated at this point.

Portal Option 3: Run the Alfresco web script engine and the portal in the same JVM. Like the previous option, this gives you the ability to write web scripts that are wrapped in a portlet but it cuts down on the size of the web app significantly and it frees up your portal to scale independently of the Alfresco repository tier. It’s a fast development cycle once you get it set up. But I haven’t seen great instructions for setting it up yet. Alfresco should document this on their wiki if they are going to support this pattern.

Portal Option 4: Write your own portlets that make services calls. This is the “cleanest” approach because it treats Alfresco like any other back-end you might want to integrate with from the portal. You write custom portlets and have them talk to Alfresco via REST or SOAP. You’ll have to decide how you want to handle authentication with Alfresco.

What about CMIS?

CMIS fits under the “Option 1: Use your favorite programming language” and “Portal Option 4: Write your own portlets” categories. You can make CMIS calls to Alfresco using both REST and SOAP from your own custom code, portlet or otherwise. The nice thing about CMIS is that you can use it to abstract the underlying repository so that (in theory) your front-end code will work with different CMIS-compliant back-ends. Just realize that CMIS isn’t a fully-ratified standard yet and although a CMIS implementation is in the Enterprise version of Alfresco, it isn’t clear to me whether or not you’d be supported if you had a problem. (The last response I saw on this specific question was a Peter Monks tweet saying, “I don’t think so”).

The CMIS standard should be approved by the end-of-the-year and if Alfresco’s past performance is an indicator of the future, they’ll be the first to market with a production-ready, fully-supported CMIS implementation based on the final spec.

Pick your poison

Those are the options as I see them. Each one has trade-offs. Some may become more or less attractive over time as languages, frameworks, and the state of the art evolve. Ultimately, you’re going to have to evaluate which one fits your situation the best. You may have a hard time making a decision, but you have to admit that having to choose from several options is a nice problem to have.

April 8, 2008

Running Alfresco web scripts as Liferay portlets

I’ve seen a lot of Liferay and Alfresco forum posts from people having trouble getting Alfresco running within a Liferay portal. Once that’s done, people usually want to invoke Alfresco web scripts as portlets without requiring a separate single sign-on (SSO) infrastructure. Some people have pointed to the Alfresco wiki (Deploying 2.1 WAR Liferay 4.3). That is a helpful reference but it isn’t the full story. Here are some notes that may help.

1. Download the Liferay 4.3.6 + Tomcat 5.5 JDK5 bundle. I had mixed results with the latest release 4.4.2. You may be tempted to try to download the WAR-only distribution and configure it in your existing Tomcat instance. In this case, save yourself the time and headache and get the bundle. Fool with the WAR distribution later.

2. Unpack the Liferay distribution and fire it up. Make sure you can log in as the test@liferay.com (password: test) user to validate that all is well with the Liferay install.

2a. Create a test user. (“Create Account” on the Liferay login screen). Remember the email address. This will matter shortly. For this discussion I’ll assume Foo User with a screen name of fuser and an email address of fuser@foo.com. Make sure you create a home directory. In this example, we’ll call it “fuser”.

2b. Verify that you can log in as your test user.

3. Shut down the server.

4. Download Alfresco 2.1.2 Enterprise, WAR only. Alfresco 2.1.1 has a known issue (AWC-1686) with the way authentication is handled for web scripts in the context of Liferay so make sure you are using 2.1.2.

5. Expand the Alfresco 2.1.2 WAR into the Tomcat webapps/alfresco directory (which you’ll have to create the first time). If you are tweaking the install (such as pointing to a specific MySQL database, using something other than MySQL, pointing to a different data directory, etc.) make sure you have copied your good set of extensions into Tomcat’s shared/classes/alfresco/extension directory.

6. Copy the MySQL connector into Tomcat’s common/lib directory.

7. Start Tomcat. When it comes up, you’ll have Liferay running and you’ll have Alfresco running, but Liferay doesn’t yet know about Alfresco. Verify that you can log in to Alfresco as admin.

7a. While you are here, create a test user account. You need to create a user account that has an email address that matches the test user account you created in Liferay. In this example you created Foo User with a screen name of fuser and an email address of fuser@foo.com so you need to create an Alfresco user with the same settings. You’ll log in to Alfresco as fuser. You’ll log in to Liferay as fuser@foo.com.

7b. Verify that you can log in to Alfresco as fuser.

8. Shut down Tomcat.

9. Now you need to configure Alfresco as a Liferay plug-in. This involves adding four files to Alfresco’s WEB-INF directory: liferay-display.xml, liferay-plugin-package.xml, liferay-portlet.xml, and portlet.xml. Why aren’t these available in the Alfresco source or on the wiki? Apparently someone tried to address this at some point because there is a link on the wiki but it is broken. Until that’s addressed, I’ve put them here.

10. Remove the portlet-api-lib.jar file from Alfresco’s WEB-INF/lib directory.

11. Re-package alfresco.war. It is now ready to hand over to Liferay.

12. Start Tomcat.

13. Find your Liferay deploy directory. If you are running out-of-the-box on Linux, Liferay’s “deploy” directory is called liferay/deploy and it resides in the home directory of the user who started Tomcat. I’m running it as root so my Liferay deploy directory is /root/liferay/deploy.

14. Copy the alfresco.war you just created into the deploy directory. Watch the log. You should see Liferay working on the WAR. He’s finding the plug-in config files and essentially deploying the Alfresco portlets.

15. Now log in to Liferay using the Liferay admin account (test@liferay.com). Go to a page, then use the global navigation dropdown to select “Add Content”. The list of portlets should appear and you should see the “Alfresco” category. If you don’t, look at the log because something is amiss. Add the My Spaces portlet to the page. You may see an error at this point but ignore it. The problem is you probably don’t have a user in Alfresco that has an email address of “test@liferay.com”, which is the currently-logged in user.

16. Log out.

17. Log in as your test user that exists in both Alfresco and Liferay (fuser@foo.com).

18. Go to the page. You should see the “My Spaces” portlet. You should be able to upload content, create spaces, etc.

Exposing your own web scripts as portlets

All Alfresco web scripts are automatically exposed as JSR-168 portlets, including the ones you create. To add your web scripts as portlets, first make sure you have authentication set to “user” and transaction set to “required” in your web script’s descriptor. Then, update portlet.xml, liferay-portlet.xml, and liferay-display.xml. Follow the pattern that’s in those files already and you’ll be fine. For example, if you deploy the Hello World web script from my web script tutorial, you need to add a new portlet to portlet.xml with a “scriptUrl” like: /alfresco/168s/someco/helloworld?name=jeff. Then you update liferay-portlet.xml and liferay-display.xml with the new portlet name or portlet ID.

Single sign-on with no single sign-on?

The web script runtime has a JSR-168 authenticator. So when your web scripts get invoked by the portlet, the current credentials are passed in. That’s why your web script can run without requiring an additional sign in. Prior to this being put in place, people had to implement Yale CAS (or an equivalent) to get SSO between Liferay and Alfresco web scripts.

What’s not covered in these instructions is that you’ll probably want to (1) configure both Alfresco and Liferay to authenticate against LDAP and (2) change the configuration of either Alfresco or Liferay to use the same credential (either username or email address) for both systems so that if you do have users logging in to both, they don’t have to remember that one requires the full email address but the other doesn’t.

Troubleshooting

If you see one of the Alfresco portlets displaying “Data is not currently available” or somesuch, try hitting
Alfresco in another tab. Log in, then log out. Then go back to the
portal and open the page again. It should work now. I’m not sure what’s going on there. I think it may have to do with me switching back-and-forth between Liferay instances (4.3.2 versus 4.4.2) so maybe you won’t see it.

Open issues

You may see an error like this:

21:22:15,965 WARN [BaseDeployer:1038] Unable to format /usr/local/bin/liferay-4.3.6/temp/20080408212212978/WEB-INF/faces-config-jbpm.xml: Error on line 5 of document file:///usr/local/bin/liferay-4.3.6/temp/20080408212212978/WEB-INF/faces-config-jbpm.xml : A ‘)’ is required in the declaration of element type “application”. Nested exception: A ‘)’ is required in the declaration of element type “application”.

I haven’t chased that down yet. I’ll update this post with a comment when I find out. I’m sure fixing that will also fix the problem that you’ll see if you try to start an advanced workflow from a piece of content displayed in the My Spaces portlet.

I was also seeing an error when trying to use the “Add Content” link in the straight Alfresco client. I think it is JSF-related. Again, I’ll update this post with a comment when it is resolved (or when I find a Jira ticket).

October 26, 2007

Exposing reports & analytics through portal gets easier

CBR Online is reporting that Liferay, an open source portal, and Pentaho, an open source business intelligence platform, are working on better integration between the two products. This is good news to Enterprise clients who often want to expose BI data such as reports and dashboards to users across the company via the web. Tighter integration through JSR-168 will make it easier to personalize and deliver Pentaho portlets through Liferay.

Mixing BI, or quantitative data and technologies, with ECM, which is more qualitative, can be powerful. Here are a couple of examples. Clients sometimes ask about reporting capabilities in Alfresco. Alfresco has pretty granular auditing capabilities. When you enable it, events get written into a set of auditing tables in your relational database. Once that happens, it’s simply a matter of using a reporting or BI tool, like Pentaho, to create all the reports you might need, and you could deliver them via your Liferay portal.

Thinking more strategically, maybe you want to monitor certain analytical aspects of your business and convene a response team if any metrics fall below a certain level. You could do that with a Liferay-Pentaho-Alfresco solution. Pentaho could generate the reports and fire of an event when a certain metric is reached. That event triggers an Alfresco workflow which routes a snapshot of the report through a workflow or creates a discussion thread in the Alfresco repository, setting permissions appropriately and notifying the members of the response team who can then use Pentaho’s analytic tools to slice-and-dice the data to their heart’s content.