Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Moving Glassfish4/Liferay to Wildfly/Liferay
It seems Glassfish is not really supported by Liferay, so I thought I'd switch to another application server.
How would I be able to do this most efficiently?
My first idea is to:
- download Liferay/Wildfly bundle
- copy /data and database over
- run upgrade tool/jar file
Would that work?
P.S. running (community version) Liferay Portal, not DXP.
Hi Maarten,
The steps you have provided seem ok but I would like to suggest the following:
- download Liferay/Wildfly bundle or Tomcat bundle
- copy /data and database over
- Startup the original version with the new server and the old databases and document library to test it and be sure that everything is ok.
- run upgrade tool/jar file
With that additional step you will separate the installation of the new server from the upgrade process so if you get any issue you will know the root cause.
I hope it helps.
Regards.
There's one small bit of data that I omitted, unfortunately. It's that I am still running 6.2 on Glassfish and the Wildfly bundle is 7.x.
Does that complicate matters?
Progress: the upgrade process of the database works fine, upgrading the data directory completes with a lot of messages.
Another question: perhaps a better way of doing this is using the LAR files that I can create? And importing them into a clean Wildfly/Liferay?
It's that I am still running 6.2 on Glassfish and the Wildfly bundle is 7.x.In that case, go ahead with the initial plan, just pay special attention to properties or any configuration/issue that can be related to the app server.
Another question: perhaps a better way of doing this is using the LAR files that I can create? And importing them into a clean Wildfly/Liferay?You can not create LARs in 6.2 and import them in 7.0, LARs must be generated in the same version where they are going to be imported.
It's common to migrate between app server before an upgrade so don't worry about that.
Please, let us know about the results.
Best regards.
Just to let you know how I'm doing:
Caused by: com.liferay.portal.kernel.upgrade.UpgradeException: java.sql.SQLDataException: Incorrect string value: '\xE5\x85\xA8\xE5\xB1\x80...' for column 'name' at row 1
Answer: my Database had characterset Latin1, changed it to UTF with a ALTER TABLE script I found on the forums.
Couldn't connect to the database.
Answer: I'm using mariadb, so I needed to switch the jar mysql.jar in the module.xml with the mariadb.jar.
After that the upgrade seemed to be going okay.
Just two things:
- my theme is completely gone (likely because I didn't upgrade it or install it in the wildfly), but resetting the current theme to classic, does not bring back the old classic theme in 6.2? Are there differences in between Classics? I plan on installing a new theme anyways.
- my Wiki seems to be non-working. I can only see the main page, and it shows all the tags and none of the formatting. Do I need to upgrade it separately, or are my settings for the Wiki wonky?
- there's no marketplace-portlet.war anymore?
Maarten van Leunen:Just two things:
- my theme is completely gone (likely because I didn't upgrade it or install it in the wildfly), but resetting the current theme to classic, does not bring back the old classic theme in 6.2? Are there differences in between Classics? I plan on installing a new theme anyways.
- my Wiki seems to be non-working. I can only see the main page, and it shows all the tags and none of the formatting. Do I need to upgrade it separately, or are my settings for the Wiki wonky?
- there's no marketplace-portlet.war anymore?
1) Your 6.2 theme will need upgrade to work on 7.0 anyways - however, I'd expect a fallback onto classic theme if the theme doesn't exist (that's just an expectation, not experience that I remember (my last 6.2 upgrade was a while ago)
2) Wiki should be part of the upgrade and continue to work. Not sure if the supported Wiki Syntax changed - what are you using? Creole? HTML? Mediawiki syntax?
3) There's no (or almost no) WAR-packaged portlets any more - it's
all in OSGi bundles and applications are no longer deployed as several
webapps (even though Liferay still is able to deploy WAR files,
they're deployed differently than in 6.2 times.
It seems most pages are set to MediaWiki.
I did some checking and it seems MediaWiki was removed in Liferay 7? Now there's only HTML, plain text and Creole?
Can that be the cause, and is it easy to change to Creole for all pages at once?
Verified: when I try to edit a wiki page it complains about the format not supported. I change it to Creole and I am good to go. (requires some edits to fix the format that isn't supported).
P.S. how can I easily change the format for all my wiki pages to Creole, without having to visit each and every one?
When attempting the upgrade on the production server after testing it, I encountered the following problem:
Caused by: java.sql.SQLSyntaxErrorException: (conn=47) Specified key
was too long; max key length is 767 bytes
at
org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:236)
at
org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:165)
at
org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:238)
at
org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:356)
at
org.mariadb.jdbc.MariaDbStatement.executeUpdate(MariaDbStatement.java:545)
at
com.zaxxer.hikari.pool.ProxyStatement.executeUpdate(ProxyStatement.java:117)
at
com.zaxxer.hikari.pool.HikariProxyStatement.executeUpdate(HikariProxyStatement.java)
at
com.liferay.portal.configuration.persistence.internal.ConfigurationPersistenceManager.createConfigurationTable(ConfigurationPersistenceManager.java:284)
at
com.liferay.portal.configuration.persistence.internal.ConfigurationPersistenceManager.start(ConfigurationPersistenceManager.java:187)
at
com.liferay.portal.configuration.persistence.internal.activator.ConfigurationPersistenceBundleActivator.start(ConfigurationPersistenceBundleActivator.java:65)
at
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:779)
at
org.eclipse.osgi.internal.framework.BundleContextImpl$3.run(BundleContextImpl.java:1)
at java.security.AccessController.doPrivileged(Native
Method)
at
org.eclipse.osgi.internal.framework.BundleContextImpl.startActivator(BundleContextImpl.java:772)
... 13 more
Caused by: java.sql.SQLException: Specified
key was too long; max key length is 767 bytes
Query is: create
table Configuration_ (configurationId varchar(255) not null primary
key, dictionary longtext)
java thread: ModuleFramework-Static-Bundles-1
at
org.mariadb.jdbc.internal.util.LogQueryTool.exceptionWithQuery(LogQueryTool.java:126)
at
org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.executeQuery(AbstractQueryProtocol.java:222)
at
org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:350)
... 23 more
So there's an index that is too large for table Configuration_?
It seems to be a small bug in mysql, it no longer truncates indexes to max size but throws a wobbler. A workaround would be to switch back to Latin, but I don't think that's a good idea, as I hear Liferay requites UTF8.
Maarten van Leunen:When attempting the upgrade on the production server after testing it, I encountered the following problem:
Caused by: java.sql.SQLSyntaxErrorException: (conn=47) Specified key was too long; max key length is 767 bytes
Well, I managed to fix this by downloading the "data"
dir and a database dump to my local machine (Fedora Core 29) and
attempting it there instead of on my Server (CentOS 7).
A upgrade on my local machine worked fine.
Apparently there's a difference in MariaDB versions.
(Will try to upload the upgraded liferay to the server)
Hi Maarten,
The error "Specified key was too long; max key length is 767 bytes" usually happens due to problems with the database enconding, please compare it between the server where it failed and the server where it passed.
I hope it helps.
Cheers!