Actually we rediscovered it . I had looked at Liferay in August 2008, to establish a community for another company; however they decided, that they could not provide the resources to host an “active” community. Part of providing a community is the nurturing and feeding of the community by providing content on a “regular” basis and responding to comments.

From 100,000 feet, Liferay is essentially an open source version of SharePoint written in Java. Liferay embraces document collaboration, Web 2.0 and social collaboration. A Liferay portal provides one or more organizations with one or more communities. Each community and user has public and private pages. Users can be assigned roles within multiple organizations and communities. Liferay plugins, portlets, can be added to any page by any user based on their “scoped” role. Liferay themes and layouts can be established at the community level or applied to each page.

Liferay provides wiki and blogging editors that can be configured to support either the FCKeditor or TinyMCE. This allows users that are already familiar with other Social media tools to be immediately productive. One of our litmus tests for wiki and blog usability is: can a user “easily” learn to how create an attractive blog or wiki that is media and content rich without having to result to editing raw HTML? This should be possible without formal training. Yeah, I expect the user would read some documentation and view some training videos; however, since more and more users are using social media sites, they are looking for their corporate tools to resemble their other tools. The workflow in these tools should allow the user to work top-down as they are thinking. Although not perfect, we find that Liferay passes this test.

One of the disruptive behaviors of internet-based systems and web 2.0 is that corporate systems and vendor applications lag many internet applications in technological advances. This means that users are often waiting for the applications that they use at work to catch up with the ones they use personally.

Liferay allows the use of existing content or the dynamic upload of content while you are are writing. SharePoint 2007 only supports use of previously stored content while editing.

Okay, I know that you can open another browser window; upload some content; and then switch back to your wiki/blog window to complete the wiki or blog entry. However you cannot imagine how many users do not think of this or understand this. I been around long enough to realize that means that there is likely a disconnect between the user’s desired workflow and the product workflow.

The Liferay wiki and blog editors work equally as well with Internet Explorer,IE, and FireFox. SharePoint 2007 provides a more robust experience to IE users. With SharePoint, in my opinion, wiki and blog editing in FireFox feels like an “unwanted disease”. This is unfortunate. There are standard JavaScript libraries that abstract browser dependencies. There is simply no technical reason that SharePoint can’t provide a first class experience to most browsers. The Liferay content portlet can contain javascript, this allows easy integration with a plethora of other social media and web-based applications. Ironically, I placed my Windows Live status with a button into a Liferay content portlet and it behaves correctly. I could not do this with SharePoint. The SharePoint editors deleted the javascript code. The Liferay Wiki can be configured to support Creole or Camel-case wiki editing.

You know, SharePoint could learn a lot from Liferay.

A little background on Java and certificates.

Java manages certificates in 2 groups:

• Root certificates and code signing certificates
• Individual site certificates

Root certificates and code signing certificates are stored in the cacerts file that is a part of the jre. Typically this is in:

• $JAVA_HOME/jre/lib/security/cacerts for Unix/Linux or
• %JAVA_HOME%/jre/lib/security/cacerts for Windows

Individual site certificates are typically stored in a “truststore” that you create and maintain.
When you start your java program you reference the truststore using the appropriate Java -D options

• “-Djavax.net.ssl.trustStore=”
• “-Djavax.net.ssl.trustStorePassword=”

All groups of certificates are managed by the java keytool program.

Unlike Web Browsers and their automatic SSL certificate acceptance of certificates signed by trusted entities, a certificate must be registered with java before it will be trusted. To do this you manually enroll the site’s public ssl certificate into the “truststore” and any missing root/signing certificates into the JVM’s cacerts file.

Updating the cacerts

Currently, Go Gaddy has 2 valid Certificate chains; “ValCert Legacy Certificate Chain” and “New Go Daddy Certificate Chain”. Our new certificate used the “New Go Daddy Certificate Chain”. I downloaded the “Go Daddy Class 2 Certification Authority Root Certificate — DER Format” and the “Go Daddy Secure Server Certifcate (Intermediate Certificate)” from the site https://certs.godaddy.com/Repository.go. I installed these into my cacerts file

This is my script to update the cacerts

#!/bin/sh
TOD=`date +%y%m%d_%H%M%S`
JAVA_HOME=/usr/java/jdk1.5.0_11
CACERT_STORE=${JAVA_HOME}/jre/lib/security/cacerts
CERT_FILE1=gd-class2-root.cer
CERT_ALIAS1=godaddyclass2ca
CERT_FILE2=gd_intermediate.crt
CERT_ALIAS2=godaddy-intermediate-cert
 
cp ${CACERT_STORE} ${CACERT_STORE}_${TOD}
if [ -f ${CACERT_STORE}_${TOD} ]
    keytool -import -trustcacerts -keystore ${CACERT_STORE} -file ${CERT_FILE1} -alias ${CERT_ALIAS1}
    keytool -import -trustcacerts -keystore ${CACERT_STORE} -file ${CERT_FILE2} -alias ${CERT_ALIAS2}
fi

You will be prompted to enter the password of the cacerts file. If you have not changed it, then it will be “changeit”

Updating your truststore

Now you are ready to enroll the public SSL certificate. In my case, the site was an IIS site and I used the Windows certificate export and picked format DER. Do not export your private key! I then downloaded the certificate to the system where the Java code was going to run and enrolled it using a script similar to the one below

#!/bin/sh
TOD=`date +%y%m%d_%H%M%S`
JAVA_HOME=/usr/java/jdk1.5.0_11
HOST=www.yoursite.com
CERT=www.yoursite.com_export_DER_x509.cer
KEYSTORE=mytruststore
 
cp ${KEYSTORE} ${KEYSTORE}_${TOD}
if [ -f ${KEYSTORE}_${TOD} ]; then
    $JAVA_HOME/bin/keytool -delete -keystore ${KEYSTORE} -alias ${HOST}
    $JAVA_HOME/bin/keytool -import -keystore ${KEYSTORE} -alias ${HOST} -file ${CERT}
fi

You will be prompted to enter the password of the “mytruststore” file. This is the value that you set when you created the truststore

To use your truststore when you run your java program

I add the ssl -D options to my JAVA_OPTS variable that I use when I run java. An example is shown below

TSTORE_OPT=”-Djavax.net.ssl.trustStore=”yourpath”/mytruststore
TPASS_OPT=”-Djavax.net.ssl.trustStorePassword=mypassword”
JAVA_OPTS=”${TSTORE_OPT} ${TPASS_OPT}”
java ${JAVA_OPTS} MyJavaProgram

In production I always store variables like these in a protected configuration file

I’ve used this approach successfully with stand-alone java applications, Tomcat, WebLogic and Jboss