Mounting Multiple CMIS Repositories on Liferay 6.1

Company Blogs February 25, 2011 By Alexander Chow Staff

Last year, there was a huge buzz about this new protocol call CMIS that just was released at 1.0.  Much like JCR, CMIS is a protocol that allows interoperability for document repositories of different systems (there is a good blog post about different use cases that can be found here).  The major advantage of CMIS over JCR is, well, it is not bound to Java.  So there are libraries for python, PHP, .NET, etc.  It also runs on top of standard web protocols like AtomPub or WebServices.

(The first section is just a bit of history.  So if you just want to know what's happening in version 6.1, skip the first section.)

The Famed CMISHook

So, in Liferay 6.0, I was tasked with allowing Liferay to hook into CMIS as a means to store its document library data.  If you have seen our JCRHook implementation, it is basically the same concept -- the CMISHook was used as a means to store our document library's low-level data.  But then, if you went to your CMIS Repository, you would have all these numbers show up in your system which make no sense whatsoever to the average user.  And if you changed anything in that repository, it would screw up Liferay because things were not synchronized.

Now WHY, some have asked, would you ever want something like this?  Doesn't this defeat the whole purpose of CMIS?  The answer to the second question is no.  The first question is much like asking why we have a JCRHook -- or an S3Hook, for that matter.  The main point is that, for some environments, you want to scale their systems in a way that a simple FileSystemHook will just not do.  It is like asking if you want to store your files on a thumbdrive, network drive or your new Thunderbolt hard disk.  This is what CMISHook did -- it gave users another option.

Liferay 6.1: Mounting CMIS Repositories

Of course, in Liferay, we were aware that the simple CMISHook was just a first step.  The next step was to completely redesign the Document Library to support multiple repositories mounted for each document library portlet.  Sergio in the Madrid office and I have been working on this redesign and now we can show a little of what it looks like.  On a Mac, this is akin to mounting my iDisk or a network drive to my Finder.  But the thing is, this is not simply CMIS -- the vision for 6.1 EE is to mount many vendor-specific repositories like Sharepoint and Documentum.  Instead of swapping my SATA drive with an SSD, you are given the option to put a SATA + SSD + FireWire.  So in 6.1, multiple repositories can be mounted to one document library -- CMIS is just the first of these.

While this is still relatively new and only in trunk, let me show you how it works.

Step 1: Credentials

The first thing you need to know is credentials.  In order to log into a CMIS repository, we need to basically pass the credentials you used in Liferay through to CMIS.  So, you need to make sure to set your portal.properties to allow Liferay to store your password in the session:

session.store.password=true 

Next, you need to make sure that the means in which you login to Liferay is the same as for your repository.  For most, this means that you need the same screenname.  So, in portal.properties, I have: 

company.security.auth.type=screenName

Of course, what this means is that if I log into, say Nuxeo using "alex" and "secretpassword", then I have to login to Liferay with those same credentials as well.  Most people would have some kind of an LDAP or something like this anyhow, so that should be fine.  Without the same credentials, obviously, you will have a principal exception and your users will be complaining to you about why they can't see their data.. you don't want that.

Step 2: Mounting Your Repository

OK, in the Document Library control panel, you will see an "Add Repository" action.  After clicking that, you will be given a form that looks like you are adding a folder -- but instead, you are adding a new repository.  (Incidentally, we made it so you can mount a repository in any folder in the Document Library -- the root level, or your sub-sub-subfolder.  As long as it is not in another third-party repository, you are fine.)

In this example, the repository type is set to CMIS AtomPub, but you can use WebServices if you like (it just has a whole lot more parameters to choose from).  For CMIS, you need to fill in all entries -- but the repositoryId is not required.  If you do not enter a repositoryId, then it will just look for the first repository using the given parameters and set it to that -- many systems only have one.

Step 3: Enjoy!

OK, after doing that, Liferay will try to talk to the other server and verify its connection.  Assuming everything goes well, a new repository is added to your list of folders.  Below, I have mounted the same Alfresco server -- once via AtomPub and again via Web Services.

Now, automatically, what you will notice is all the data that is stored at the Alfresco repository has been linked into Liferay.  Just to verify, you can look at the files and folders in Liferay and compare them to Alfresco.  Here's Liferay:

And here's Alfresco:

Obviously, any CRUD operation you do on Alfresco will be reflected on Liferay and vice versa.

CMIS Superstar?

For many, CMIS is perhaps the best thing since sliced bread.  And in fact, as an interoperability protocol, it is pretty darn good.  HOWEVER, all protocols come with shortcomings.  Remember, CMIS is quite new (it is only at 1.0 right now) and has a lot of room for growth.  A couple things to be aware of before you throw away that bread slicer you got for Christmas..

  • CMIS does not give vendor-neutral specifications for many features found in Liferay or other repositories... like workflow.  CMIS does not yet specify how a workflow is to be started and its different stages, etc.  This is something that is in the discussion for CMIS v2.0.  So, if you noticed, I mentioned Sharepoint and Documentum.. both of which are supposed to have support CMIS.  The reason why we are building out vendor-specific repositories for 6.1 EE is because CMIS does not solve all the woes of integrating legacy systems into Liferay.
  • Another fundamental item that is not supported by CMIS is a vendor-neutral way of managing metadata.  There is no adhoc metadata, tags/categories, etc.  Nuxeo, for example, stores their data as part of the CMIS file's properties using Dublic Core notation.  Alfresco, on the other hand, builds things in the "extended" space of CMIS properties and brings in their proprietary "aspects."  There are proposals out there for having a fundamental feature as metadata included in at least CMIS v1.1 (see here and here).  But as of today, this does not exist. We are hoping to build out some of these vendor-specific attributes ontop of CMIS, but there are so many vendors out there that have their own way of supporting the standard.  Just Nuxeo and Alfresco alone have quite different implementations.
  • Another thing you will notice is speed.. or the lack thereof.  If you are going to use everything on another server and have it translated into AtomPub or WebServices, over the wire to another server that has to translate it back to its native format... yah, it will get a performance hit.  I mean, within our code, I try to cache as much information as possible, but it is still noticeably slower on my system (of course, I am running multiple servers on my non-thunderbolt-equipped MacBook Pro).  It is like when I backup my wife's computer -- I always plug in and never do it over the WiFi.

Conclusion

All in all, CMIS is not a bad protocol.  In fact, it is an excellent protocol.  But, like all protocols, there is always a tension between the generic protocol and the genius of different vendors, trying to solve different problems for their customer's needs.

For us, we have gotten quite a few requests to support legacy repositories.  We have no problem with that.  In fact, that is the whole point of a portal – as an aggregator of information from vastly different technologies.  However, it required a complete overhaul of the backend to do it (the 6.1 document library API is VERY different.. but you can't tell, can you?).  Hence, the addition of CMIS as a separate repository in our document library, just adds to the greater ecosystem Liferay supports.  Customers like that.  And therefore, we do too.

Give her a spin and let me know how it goes.  Thanks for reading.

 

Visiting Liferay Madrid

Company Blogs February 11, 2011 By Alexander Chow Staff

One of the nice things about working for Liferay is the flexibility I have in where I can work.  Though originally from LA, my wife and I currently live in the UK and I work from home in the UK.  While this is great for many reasons, it is also really hard to collaborate with colleagues.

Well, this past week, I had the great privilege of spending some focused time with my superstar colleagues in Liferay Madrid.  In particular, it allowed me to work closely with Sergio in hammering out some critical engineering for Document Library for 6.1, including a more flexible paradigm for mounting multiple repositories (in particular, CMIS), and have some really good discussions with Julio for some other design work.  Overall, it was an incredibly productive time and these Spaniards have been really hospitable to me.

Here's a few shots... the office: 

 Julio showing how much he likes using the whiteboard to draw out designs:

And, of course, tapas y cañas!!

 Hasta luego, Madrid!

Live Preview for Document Library

Company Blogs January 31, 2011 By Alexander Chow Staff

Liferay's engineering team has been doing a lot of work on the Document Library for version 6.1.  But in one of the recent weekly meetings, a discussion sparked off about the possibility of having some kind of live preview for the Document Library.  This is meant in terms of both (1) thumbnails of files in the file listing and (2) previews of the actual document that you can go through without downloading the file.   So, after a little toying around, I got a first cut of this working in trunk (see LPS-13145).  Both of them still need to be reskinned (our UI guys are great at that), but I thought I would show a few screenshots of what things roughly look like.

For thumbnails (note that the future version will allow you to pick a plaino list view vs. a thumbnail'd view):

Then, you can also go through each page of the document as well (eventually with zooming capabilities):

 

How does it work in the backend?  Well, first, it converts files to PDF format using OpenOffice.  So you need to make sure you have that installed.  Then, it breaks up the PDF into images -- one for each page.  Now, OOTB, it does it using PDF-box.  But, ideally, you should install ImageMagick.  This is because PDF-box is great for fairly simple PDF documents, but can get a bit gibberish if you use fonts it doesn't know about and things like that.  ImageMagick also runs significantly faster.  So, all in all, it is much better if you install ImageMagick.

Developing with Java for Mac OS X 10.6 Update 3

Company Blogs December 1, 2010 By Alexander Chow Staff

In October, Apple released for OS X  their latest update of Java.  (There was this whole hoopla about whether or not Java would cease to exist on OS X, but then Apple announced that it would be releasing much of its source code to OpenJDK -- discussions around that are not the topic of this blog post.)

One of the side-effects of that release was that Apple decided to move around several of its directories (some have supposed this would allow third-party releases of the JDK to be installed more easily).  In any case, if you are like me, you constantly look to the source code of the JDK to understand what is happening in things like java.util.HashMap, java.lang.String, etc.  Before, there was a classes.jar file you could find things in.  Now, they changed it to a src.jar file.  On my system, I did the following in the commandline:

liferay 12:10:31 ~> find /System/Library/Java /System/Library/Frameworks /Library/Java -name src.jar

/Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home/src.jar

 
If you don't find that, you may have to install the Developer Package for the update from Apple's developer connect site (why you have to install it separately now, is beyond me).  You can then attach this jar in Eclipse or whatever IDE to navigate through the JDK source.

Incidentally, if you are interested in the javadocs, there are appledocs.jar and docs.jar that can be found in the same directory.

WebDAV, Digest Authentication and Windows Vista/7

Company Blogs August 24, 2010 By Alexander Chow Staff

For a while now, Liferay has offered Basic authentication for various servlets (e.g., WebDAV, JSON, etc.).  For the most part, this has suited most of our needs.  However, recently, there have been some client applications that now require the more stringent Digest authentication system.  To support these requirements, digest authentication has been added to Liferay.

In particular, two WebDAV clients have added this requirement: Windows Vista and Windows 7.  Since most WebDAV clients support both basic and digest auth, this has been enabled by default.  You can only have one enabled at a time.  But you can switch WebDAV back to basic auth (or any other servlet to digest auth) in your tunnel-web/web.xml:

<filter>

    <filter-name>Secure WebDAV Servlet Filter</filter-name>

    <filter-class>com.liferay.portal.kernel.servlet.PortalClassLoaderFilter</filter-class>

    <init-param>

        <param-name>filter-class</param-name>

        <param-value>com.liferay.portal.servlet.filters.secure.SecureFilter</param-value>

    </init-param>

    <init-param>

        <!-- <param-name>basic_auth</param-name> -->

        <param-value>digest_auth</param-value>

        <param-value>true</param-value>

    </init-param>

    <init-param>

        <param-name>portal_property_prefix</param-name>

        <param-value>webdav.servlet.</param-value>

    </init-param>

</filter>


How does this change how we use WebDAV (or anything else with digest authentication).  For the average user, it does not change much.

What you need to know, however, is that if you are using a new installation of Liferay or just upgraded or something like that, you won't be able to log into WebDAV initially.  Rather, you must first login through the portal.  Why?  Because, the algorithm dictated by the RFC requires the server to have a hash based on your login credentials.  Since Liferay never stores a raw password, it can only create the hash based on credentials passed in when a user logs into the portal.  This also means any changes to a user's email address or screenname would require the user to relogin before they can login via WebDAV again (since we allow WebDAV credentials of all three types).

For Windows Vista and Windows 7 users... you still may not be able to use WebDAV to its full potential (at least on 6.0 CE GA3 and below).  Reason being, literally the day after we released GA3, I fixed a bug that only shows up in Windows Vista and Windows 7.  Basically, Microsoft changed their WebDAV client implementation to check certain things that it did not do in the past.  Therefore, while you are able to mount and use Liferay's WebDAV, you cannot do certain basic file system operations that are traditionally supported on WebDAV... unless you have the patch (which will definitely be in the next releases of CE and EE).

The basics of this information can be found in our wiki.

Pingbacks Aren't Only for Blogs

Company Blogs March 1, 2010 By Alexander Chow Staff

 After writing up about adding pingbacks to blogs, I realised that there could be an additional area where pingbacks would be quite useful -- message boards.  So, with a few changes in code, 6.0 will be coming with a new feature that allows messages to post pingbacks to any blogs (or any other pingback consumer).

So, when you post a message that contains a URL to any pingback consumer:

Then, a few minutes later, it appears in the blog:

As usual, this can be disabled for the site or each particular message.

Blogging about Blogging

Company Blogs February 24, 2010 By Alexander Chow Staff

One of the nice, collaborative features in blogs these days is the ability to leave comments.  But what if you, on your blog, are trying to comment about something somebody else blogged about?  Well, you would use some kind of linkback that would refer to the other blog, and leaves a comment on their blog that you were there.

Previously, we implemented trackbacks as a basic way for doing this.  If you've ever posted a blog message, you have undoubtedly seen the "Trackbacks to Send" field below your content.  You would enter their trackback URL there and, if all goes well, you will see a comment on the other blog that refers back to yours.  In most systems the trackback URL is different from the post URL.  So, for example, Liferay's trackback URL looks something like this:

http://localhost:8080/web/test/home/-/blogs/trackback/this-is-my-blog-entry

As opposed to the actual blog entry URL which looks like this:

http://localhost:8080/web/test/home/-/blogs/this-is-my-blog-entry

I've got to find this person's trackback URL, and copy and paste it into my blog.  Suffice it to say, this is actually a bit cumbersome.  

Well, in comes pingbacks (being introduced in Liferay v6.0).  Pingbacks are a version of linkbacks that is much more simple to use.  Why?  Because you don't really have to do anything!  So let's say somebody posts a message that I though was pretty interesting.  All I do is link that blog URL in the body of my blog entry.  I would normally be doing that anyhow.

When you publish the blog entry, Liferay will scan through its contents and look for any hyperlinks (<a href=""> tags). If it finds any, it will check with each URL to see if it supports pingbacks (support is normally indicated by the presence of an X-Pingback header for that page). If it does, a few minutes after the entry is posted, Liferay posts an XML-RPC call to the pingback server telling the server that you just mentioned their blog entry in yours. If everything checks out ok, then in the other person's blog, you will see a comment summarising and linking back to your entry.

Voila!

You can of course turn this option off if you like.  Liferay blogs will also work as both consumers and producers of pingbacks, so it will talk to other servers like WordPress or Moveable Type.  Incidentally, Blogspot does not support pingbacks or trackbacks, too bad. :(

Document Library Hooks Migration

Company Blogs December 16, 2009 By Alexander Chow Staff

A few months ago Minhchau created a migration tool to move document library files from using one hook to another (e.g., JCRHook to AdvancedFileSystemHook).  He showed the code for it and wrote several plugins to handle this.  Due to popular request, this has now been moved into trunk!  I just checked in the code to help facilitate a move from one hook to another.

CMIS and Database Migration

Company Blogs October 16, 2009 By Alexander Chow Staff

When I was at the European Symposium, I was surprised how many people said to me "Gosh I wish Liferay could do ABC," in which I responded, "But it has -- ever since version X.YZ!"  But I guess part of that is my fault since I don't blog that much about my work.

In any case, I just wanted to highlight two features coming out with 5.3 that some people may be interested in.

1. Content Management Interoperability Services (CMIS)

This is a new standard that's been brewing to allow for different CMS systems to interchange information.  It is basically another JSR-170 with two important differences: (1) it is not Java-specific and (2) it is document-manangement-centric.  So, our PHP friends, for example, can make a CMIS repository that can be accessed by Liferay or any other CMIS consumer.  For us, we interoperate with a several different types of repositories (e.g., JCR, S3), so I basically just built a hook for CMIS.

If you were interested in enabling this feature, you need to have a CMIS producer setup, and in your portal.properties configure the following:

    dl.hook.impl=com.liferay.documentlibrary.util.CMISHook
    cmis.credentials.username=none
    cmis.credentials.password=none

Also, depending on your CMIS producer, you may have to change the repository URL.  That's about it!  Just one note... CMIS is currently not finalised so it is still at version 0.61.  I'm following the changes in the standard so when it gets to 1.0, we should be able to support that without much trouble.

2. Database Migration

Have you ever setup an entire project, then wonder why you were using the default demo DB Hypersonic and wanted to move to something else?  Or for some reason, just enjoyed changing DBMS every other week?  Well, if you do, I've got news for you -- you can now migrate the data from your existing database to a new one.

All you have to do, is create a new schema in your new database, go to the "Data Migration" tab under the "Server Management" control panel, fill in the JDBC information, and voila!  Data is moved.  After everything is done, your server will be shutdown.  Remember to change your portal.properties to point to the new database, and startup your server again.

Okay, that's it for now.  Next time I'll try to come out with updating more frequently.

Sharding Databases - An Unorthodoxed Design

Company Blogs March 19, 2009 By Alexander Chow Staff

 I have been recently working on the very interesting task of making the Liferay database shardable.  What does this mean?  There is a good introduction to shards here, but basically it is a way of scaling your database horizontally.  For a given table or set of tables, you split up the data that is stored and fetched based on a given hash or something like that.  Instead of storing a gigabyte of user data on one database, you spread this data across.. let's say, a dozen shards.  This way you don't overload one database, have smaller queries (since each table has less data now), and have better overall throughput under load because all your IO is not going through one database server.  Google, Facebook, Wikipedia -- all these guys shard their databases.

Nice concept, but how does it work in Liferay?  Well, as sort of a quick initial use case, I tried to shard the system based on portal Instances.  This is great if you are working in an ASP (Application Service Provider) environment where you host multiple portals on a single running version of Liferay.  So, in a nutshell, what we do is we use Spring to intercept calls to the persistence tier, figure out what the companyId is (that which designates the Portal Instance), and switch out the DataSource underneath you before letting you continue.  When there is a need to make calls across all databases (e.g., UpgradeProcess), we catch it in Spring and make the appropriate call multiple times across each of the shards.  With that, you now have a sharded database!

In the future, we are looking to shard other things... Users, Communities, Layouts, Portlets, etc.  But for now, this is our first cut.

If you would like to try it out yourself, check out the wiki article.

Tunnel-web without JAAS

Company Blogs April 4, 2008 By Alexander Chow Staff

In a previous post, it was suggested to me that I remove tunnel-web's dependency on JAAS.  What this would do is (1) circumvent issues with JAAS implementations in certain app servers (Tomcat's bugs and the lack of configuration in Glassfish) and (2) allow users to log in using the same login credentials they would use on the portal's signin page (normally, the email address).  As of the upcoming 5.0 release of Liferay Portal, this now exists.  The exciting thing for me is now WebDAV feels so much nicer!  :)

However, if there is some reason you need to login a tunnel-web servlet via your userID, you still can -- just append @uid (e.g., 12345@uid).  Alternatively, you can append @sn to your screenName (e.g., achow@sn).  This was necessary to allow for certain use cases in which the user ID was still needed and was the only thing available.

This blog post is long overdue (since I added this feature a while back), but I've been busy with other things so haven't had a chance to blog about it.  As way of paying penance for this transgression, I am posting a rare, one-of-a kind photograph of our esteemed Founder and Chief Software Architect:

Brian Chan at Retreat

This photo was taken while Mike Young and family and I were driving up to the last annual retreat, where there was no internet access, and we saw somebody with long hair sitting in a car parked at the entrance.  Evidently Brian was using his BlackBerry for internet, could only get reception outside, and was committing code!  He is quite a faithful one indeed!!

Reskinned Image Gallery

Company Blogs March 14, 2008 By Alexander Chow Staff

I don't know about you, but I was not too fond of the Image Gallery display (sorry Brian). So, I decided to get out of my back-end shell, and try a little Javascript and CSS madness! Now, when viewing a given folder, you are shown a grid of thumbnails instead of a list of images. Here's a couple of snapshots of what I did:

   

Let me know what you think and any other improvements in that area I can do -- but be forewarned, I am not a front-end developer!

Little Steps with WebDAV

Company Blogs February 21, 2008 By Alexander Chow Staff

For the last month or so, my focus has been to slowly improve Liferay's WebDAV capabilities.  WebDAV is an incredibly powerful way of accessing data on the portal, but there is always room for improvement.  So, I am blogging to report that there will be some minor improvements in 5.0 (and some bits in 4.4.2).  Here are just a few of the little things that we should be seeing in the next major release of Liferay Portal.

 

Friendlier WebDAV URLs

So, at present, WebDAV URLs look something like this:

http://localhost:8080/tunnel-web/secure/webdav/document_library/3409/5402/dlfolder/

http://localhost:8080/tunnel-web/secure/webdav/journal/3409/5402/Structures/

Now, this may be nice for some people, but there are two fundamental problems: (1) why are there numbers in this path (3409 = companyId and 5402 = community/groupId) and (2) shouldn't the path to the portlet be after the company and group identifiers?  Those are great questions, Joe Bloggs!  Now, in 5.0, the URLs are more intelligent:

http://localhost:8080/tunnel-web/secure/webdav/liferay.com/joebloggs/document_library/dlfolder/

http://localhost:8080/tunnel-web/secure/webdav/liferay.com/joebloggs/journal/Structures/

Not only that, but you can now also navigate down to:

http://localhost:8080/tunnel-web/secure/webdav/liferay.com/

and see all the communities that the user is allowed to see.  Going down to the community level will also allow you to see the different WebDAV storage systems that are available.  That required quite a bit of refactoring, so be glad it all works!  :)

 

Image Gallery WebDAV

Another major request by many WebDAV enthusiasts has been the inclusion of the Image Gallery in WebDAV.  But, to make them easier to manage from a UI standpoint, I also introduced names for images.  So, when you upload an image, you can now give it some intelligable name.  This way, when you look at the WebDAV directory, you can see all the files via the names.

And additional feature that was added in the process was making the WebDAV storage system plugable.  Meaning, if you have some other portlet or collection of portlets that you want to implement WebDAV for, all you have to do is extend off of the BaseWebDAVStorageImpl class, add it to portal.properties, and *BAM* you have WebDAV.

 

WebDAV Stopped Working in 4.4.0 and 4.4.1?

So, there has been several people complaining about WebDAV not working in 4.4.0 or 4.4.1.  This, I was totally confused about because I ran WebDAV all the time (albeit, running from trunk).  So, how could there be a problem?  Well, it turns out that there was a bug in the Tomcat version we bundled with 4.4.0 and 4.4.1.  According to Tomcat's change log, versions 5.5.24 and 5.5.25 (the one that Liferay 4.4.x is bundled with) had broken JAASRealm.  But I thought we weren't using JAAS.  Well, we are -- in WebDAV.

 

Still to Come...

One other major feature that will be added to WebDAV is Class 2 compliance (probably, initially, only with Document Library).  This is to allow different clients to be able to lock a resource before updating it.  Clients like Mac OS X and Microsoft Office will not allow dynamic editing of resources without the locking capability.  This is a pretty significant feature, so we will see if I can get it out by 5.0.  I'll keep you posted.  :)

WebDAV Class 1 Compliance

Company Blogs January 15, 2008 By Alexander Chow Staff

After several months in the working, we finally got Liferay's Document Library compliant to WebDAV Class 1, per RFC2518!!  It is still not Class 2 compliant, meaning locking does not work (and that also means Office and OS X still cannot edit files directly in the Document Library).  But, achieving Class 1 compliance is the necessary prerequisite and we are finally there!  Here are the WebDAV litmus test results:

-> running `basic':
 0. init.................. pass
 1. begin................. pass
 2. options............... WARNING: server does not claim Class 2 compliance
    ...................... pass (with 1 warning)
 3. put_get............... pass
 4. put_get_utf8_segment.. pass
 5. mkcol_over_plain...... pass
 6. delete................ pass
 7. delete_null........... pass
 8. delete_fragment....... pass
 9. mkcol................. pass
10. mkcol_again........... pass
11. delete_coll........... pass
12. mkcol_no_parent....... pass
13. mkcol_with_body....... pass
14. finish................ pass
<- summary for `basic': of 15 tests run: 15 passed, 0 failed. 100.0%
-> 1 warning was issued.
-> running `copymove':
 0. init.................. pass
 1. begin................. pass
 2. copy_init............. pass
 3. copy_simple........... pass
 4. copy_overwrite........ pass
 5. copy_nodestcoll....... pass
 6. copy_cleanup.......... pass
 7. copy_coll............. pass
 8. copy_shallow.......... pass
 9. move.................. pass
10. move_coll............. pass
11. move_cleanup.......... pass
12. finish................ pass
<- summary for `copymove': of 13 tests run: 13 passed, 0 failed. 100.0%
-> running `props':
 0. init.................. pass
 1. begin................. pass
 2. propfind_invalid...... pass
 3. propfind_invalid2..... pass
 4. propfind_d0........... pass
 5. propinit.............. pass
 6. propset............... pass
 7. propget............... pass
 8. propextended.......... pass
 9. propmove.............. pass
10. propget............... pass
11. propdeletes........... pass
12. propget............... pass
13. propreplace........... pass
14. propget............... pass
15. propnullns............ pass
16. propget............... pass
17. prophighunicode....... FAIL (PROPPATCH of property with high unicode value)
18. propget............... FAIL (No value given for property {http://webdav.org/neon/litmus/}high-unicode)
19. propremoveset......... pass
20. propget............... pass
21. propsetremove......... pass
22. propget............... pass
23. propvalnspace......... pass
24. propwformed........... pass
25. propinit.............. pass
26. propmanyns............ pass
27. propget............... pass
28. propcleanup........... pass
29. finish................ pass
<- summary for `props': of 30 tests run: 28 passed, 2 failed. 93.3%
-> running `locks':
 0. init.................. pass
 1. begin................. pass
 2. options............... WARNING: server does not claim Class 2 compliance
    ...................... pass (with 1 warning)
 3. precond............... SKIPPED (locking tests skipped,
server does not claim Class 2 compliance)
-> 1 test was skipped.
<- summary for `locks': of 3 tests run: 3 passed, 0 failed. 100.0%
-> 1 warning was issued.
-> running `http':
 0. init.................. pass
 1. begin................. pass
 2. expect100............. pass
 3. finish................ pass
<- summary for `http': of 4 tests run: 4 passed, 0 failed. 100.0%

What is the moral of the story?  Standards are both (1) a pain to implement but (2) are worth the work.  They are a pain to implement because they have all these little things (like custom properties for WebDAV resources) that no WebDAV client actually uses -- but exists "just in case" they are needed.  But, at the same time, when you get it all there, all WebDAV clients will behave the same way.  And THAT is what we like.  Ok... I'm just babbling now since it is 1:30am... time to go to bed.  Tomorrow, I shall start on Class 2 compliance....

Liferay on Native JBoss-Tomcat

Company Blogs December 19, 2007 By Alexander Chow Staff

A few weeks ago I blogged about Tomcat's JNI native library.  Recently, I have been at a client site trying to squeeze every bit of speed out of the servers while running on a deployment with JBoss-Tomcat.  Now, I realized that you could not just run the standard Tomcat APR code because JBoss makes their own customizations to get Tomcat to run.  Rather, JBoss distributes what they call JBoss Native (version 2.0.1 will work fine with JBoss AS 4.0.x) -- their own version of the Tomcat APR.  The installation is fairly straight forward, although JBoss does not distribute OS X binaries (see wiki).

But how does it perform?  Since I was at a client site and we were running performance tests on the system and hammering it with hundreds of concurrent users, I thought I would see how much speed I could get from the native code.  For most processes, I was seeing as high as 20-25% speed boost!  Moral of the story... native code rocks!!

Tricks for Debugging Liferay

Company Blogs December 4, 2007 By Alexander Chow Staff

In the last few weeks I have spent quite some time trying to debug some weird problems on deployments of Liferay.  Here are a few tricks that I have come across that have proven to be pretty useful.

1. Monitoring Memory and CPU usage

This is pretty basic and is quite helpful in performance tests.  Monitoring these aspects will help determine if a system is memory-bound or CPU-bound.  For the memory bit, Sun provides a nice set of tools called jvmstat to watch how garbage collection is doing on your system.  If you see the GC running too often or collecting huge amounts of memory at a time, that probably means you need to fix your JVM parameters.  For the CPU bit, your operating system usually comes bundled with some kind of CPU usage monitor.  In the case of the Mac OS X/Linux/Unix breed, you can use iostat or vmstat.  For Windows, you can use the bundled administration tool called Performance Monitor.

2. Getting Thread Dumps

Now, if you think you are deadlocking somewhere or spending way too much time in certain blocks of code under load, a pretty useful test is to gather thread dumps of the JVM.  This will tell you what every thread on the portal is doing at a given point in time.  Not sure how to do this on Windows, but under Mac OS X/Linux/Unix, you can do a kill -3 <pid> and your portal's log file will now have a bunch of information on what each thread was doing at the moment in time.  Don't be afraid of this command -- it will not kill your server (unless, of course, you do a kill -9 <pid> or something like that... so don't ).

3. Remote Debugging

So in this scenario, you are running your portal on server X and you have all your debugging tools on laptop Y.  Well, if using Tomcat, you can start your portal with the command catalina.sh jpda start and it will enable remote debugging.  Then, using Eclipse or another IDE on laptop Y, you can start the debugger and hook it into a remote Java application on localhost port 8000.  You can then step through code and set breakpoints as though you were debugging code on your own laptop.

Hope that helps.  And if all else fails, search the Internet -- it never lies.

Pentaho Sample Portlets and Liferay

Company Blogs November 27, 2007 By Alexander Chow Staff

Pentaho has created a set of sample portlets for integration with a JSR-168 compliant portlet container.  Though not designed explicitly for Liferay, I have started a Wiki for the installation of these portlets on Liferay.

Liferay-Tomcat Speed Boost

Company Blogs November 10, 2007 By Alexander Chow Staff

If you are running Liferay with Tomcat, you have most likely come across this annoying message upon startup:

INFO: The Apache Tomcat Native library which allows optimal performance...


This is Apache's subtle hint that you can speed up Tomcat.  I decided to see how much of a boost it would give you.  Without the JNI library installed, I get this on startup of a vanilla 4.3.3, bundled with Tomcat on JDK5:

INFO: Server startup in 14463 ms


after installing the JNI library, I get about a 10% improvement:

INFO: Server startup in 13266 ms


This, of course, is no sophisticated metric.  But, every bit helps.  Try it yourself and let me know what kind of speed difference you are getting.  Also, feel free to update the Wiki I have started on this subject since, of course, I only have the installation working on a Mac.  :)

Liferay on Mac OS X

Company Blogs October 30, 2007 By Alexander Chow Staff

Most engineers in Liferay, Inc. happen to be Windows users.  Me, I've got one of the few MacBook Pro's in the company.



Ever since I joined the company in May 2005, I have used Macs to do my development.  In fact, I have been using Macs since 1994.  Sure, I am in the minority, but I do make a ruckus when things break on Safari.  Anyhow, in honor of the growing number of Mac advocates out there, I have started writing a Wiki article that covers the basics of getting Liferay running on your own Mac.  :)

http://wiki.liferay.com/index.php/Development Environment (Mac OS X)

P. S. If you were curious, Liferay compilation time is shorter on the Mac OS X than that other OS. :P

Showing 19 results.
Items 20
of 1