Hello good People,
I recently updated a Liferay 6 EE SP1 to 6 EE SP2 and would like to share my experience (and fixes) with you, as I think it might be helpful to you as well. I used the standard Liferay upgrade process.
My environment:
a) Liferay 6 EE SP1 (totally virgin) on tomcat, mysql, windows 7
b) Liferay 6 EE SP1 on tomcat, oracle 10, linux (don’t know exactly which distribution)
The Upgrade Process:
- configure Liferay 6 EE SP2 to use the database of LR 6 SP1 and add the property upgrade.processes=\com.liferay.portal.upgrade.UpgradeProcess_6_0_12 to your portal-ext.properties
- Start Liferay (and probably see the first error messages)
My experience 1:
- The first exception I got was related to Quartz Job Details data. The scheduler runs before the upgrade but the data is not yet changed to the new code base. I ignored the exception at this point, it did not show up after the upgrade finished successfully.
- The second exception was again related to Quartz. The UpgradeSchedular class failed with the following (part of the) stack trace:
1Caused by: com.liferay.portal.kernel.upgrade.UpgradeException: com.liferay.portal.kernel.upgrade.UpgradeException: java.io.InvalidClassException: com.liferay.portal.kernel.messaging.Message; local class incompatible: stream classdesc serialVersionUID = -1634212251253319200, local class serialVersionUID = 4711840537427854493
Now, what do we learn: a serialized object from the database cannot be de-serialized. I discovered that the implementation of the mentioned class changed and Liferay did not for any model class implement a fix serial version id.
Workaround:
Add a private static field for serialVersionUID and assign the needed serialVersionUID from the log message to Message.java, compile the class (probably by importing the source project into eclipse), and replace the Message.class in the tomcat/lib/ext/portal-services.jar by the newly compiled version.
- After the change the upgrade process ran successfully.
My experience 2:
- On environment b) (oracle database) the upgrade process for the new virtual host table failed, but didn’t tell me so. I later recognized that almost all links (e.g. the links in my_places) where converted to links without a hostname. Yes, I was as stunned as you ;-) no hostname. After debugging the ViewAction.java for my_places I figured that the UpgradeVirtualHost.java didn’t quite do its job. It was supposed to make entries based on the company table’s virtualhost column and the layoutset virtualhosts column. But it didn’t. Now why is that? Turned out that the statement that was supposed to read the old data from the database doesn’t return any rows from the oracle database (but it does for mysql). The statement ended on <<where virtualhost != ‘’>> (StringPool.BLANK was used).
Workaround:
Use the process above and replace the class UpgradeVirtualHost in the portal-impl.jar of your Liferay installation. In the class replace StringPool.BLANK by StringPool.SPACE.
A note: whenever the upgrade fails you should do a rollback of your database. Otherwise data could be touched twice by the upgrade process, and you might end up with duplicated lines in your database.
I hope this helps and Liferay addresses the problems soon. I feel that those basic upgrade behavior should have been tested and fixed before distributing a service pack. I’d say all in all I spent about 6 hours with figuring out the workarounds. 6 hours of my time and my customer’s money.
Take care and have fun.
stephan
Be kell jelentkezni ahhoz, hogy ez helytelenként legyen megjelölve.
