5.1.0 Upgrade Problem

[Josh Asbury, modificado 15 Anos atrás.]

I just pulled down the 5.1.0 Tomcat bundle and ran it against my existing MySQL database. Watching the logs, everything appears to go through just fine, but when I load up 127.0.0.1:8080, I simply get "You do not have permission to view this page." I don't see anything in the logs that indicates there is a problem. Could someone give me an idea of where to look?

FWIW, I created a new database using the provided SQL scripts, and everything loads up just fine.

[Rob Sonke, modificado 15 Anos atrás.]

Exact the same problem over here

I'll look into the update sql script in the next days.

[JR Houn, modificado 15 Anos atrás.]

From portal.properties:

    #
    # You can add additional property files that overwrite the default values by
    # using the "external-properties" system property.
    #
    # A common use case is to keep legacy property values when upgrading to
    # newer versions of Liferay. For example:
    #
    #     java ... -Dexternal-properties=portal-legacy-5.0.properties
    #

Try adding "-Dexternal-properties=portal-legacy-5.0.properties" to your /bin/setenv.bat

-jr

[Michael Reiche, modificado 15 Anos atrás.]

Or put the important property from portal-legacy-5.0.properties:

permissions.user.check.algorithm=2

in the file:

webapps/ROOT/WEB-INF/classes/portal-ext.properties

which is read anyway

[Josh Asbury, modificado 15 Anos atrás.]

Michael Reiche:

Or put the important property from portal-legacy-5.0.properties:

permissions.user.check.algorithm=2

in the file:

webapps/ROOT/WEB-INF/classes/portal-ext.properties

which is read anyway

Awesome. That worked like a champ!

[Rob Sonke, modificado 15 Anos atrás.]

That definitely works but is not what you should want. The new permission algorithm is much faster.

I would really like to know how I can migrate to that new algorithm with an existing db

[Thomas Kellerer, modificado 15 Anos atrás.]

Michael Reiche:

permissions.user.check.algorithm=2

Using this property got rid of the "You do not have permission" error when displaying the homepage.

But I cannot log into my portal anymore.

I created an "empty" portal by using the "minimal" scripts with 5.0.1

I replaced the installation with the new Tomcat 6.0 bundled, adjusted the JDNI datasource and started the portal.

But when I try to login with the correct credentials, nothing happens. The login page is displayed again. No error message (neither in the browser nor in the Tomcat console)

Am I missing something?

I would also like to ask the same question as Rob Sonke: how can I migrate an existing database to use the new permission alogrithm?

Thanks
Thomas

[Ray Augé, modificado 15 Anos atrás.]

Hello All,

About migrating from the original permission algorithm ([tt]permissions.user.check.algorithm=2[/tt]) to the new algorithm ([tt]permissions.user.check.algorithm=5[/tt]), we do not, as of yet, have a process to handle the migration.

Therefore, I can't recommend, at this time, using the new algorithm against an upgraded DB.

If you are migrating from a legacy version (anything pre 5.1) this what you should have as a permission configuration in order to maintain backward compatibility:

    permissions.checker=com.liferay.portal.security.permission.AdvancedPermissionChecker
    permissions.user.check.algorithm=2

Sorry to be the bearer of bad news, but the new algorithm was experimental code as little as two weeks ago... and having followed the natural course would probably not have been introduced into the core for a couple more months (probably around 5.2)... unexpectedly, there was a critical need for some major performance improvements and so the code became a candidate for that. Unfortunately, this means that there was no time for developing migration code.

BUT, I will likely be working on this process in the near future (near future is probably span of about 1 month, so let's say September), unless someone else takes up the torch and contributes to writing it.

Here is another thread on the topic:
http://www.liferay.com/web/guest/community/forums/-/message_boards/message/1105143

Here are parts of a conversation I had with Jesper Weissglas on the issue and some ideas I have regarding this process.

Jesper Weissglas:

OK, given the fact that we have rather severe performance problems, I am
prepared to put some effort into accelerating that.

If I run with algorithm=5 and SimpleChecker (which I now know is not a
viable real setup, but anyhow) the page rendering is about 5 x quicker
for pages with 15-20 portlets on.

Very near future = someone already working on it?
Or else, is there any written specs for what's needed?

/j

Ray:

Well, saying that there is someone on it wouldn't be true. Saying that many of us are aware that this is an important piece of making the new permission a feature and not anything else, is also true.

It's been discussed amongst Liferay developers.

The logic is essentially that we need to process all the existing user permissions and whittle them down to Role permissions.

That statement really needs to include permissions assigned to any objects which are not Roles (Community, Org, User Group, User).

Ray:

For example, as we're going through the process, we basically make a determination:

"Has this user's permission on this resource changed from the default assigned to the default Role associated with that scope?"

IF NOT ignore and throw away that permission... (say during the process we just keep a reference to that permission resource because we will later delete it).

IF SO, then we have to map the permission to either an already assigned Role of the user... or a new Role assigned to the user...

Once that's done.. we can either leave it that way... or we can post process the newly created Roles to see if there are any which can be merged into one Role assigned to many users..

We keep doing this until we have exhausted all possibilities.

Finally, we could delete the old user permissions... OR for safety we could hang onto them, noting that from that point they will not be updated if using the new alg.

So, we have a plan of how to implement the process, we are aware of the need for the process... we are in need of people to put that process together or even just to solidify the logic we should use in the design.

Ray

So again, our apologies for dangling this carrot in front of everyone faces without immediate hope of you getting a bite... that wasn't really our intention.

Ray

[Rob Sonke, modificado 15 Anos atrás.]

Thanks for your explanation! When I see "performance improvements" somewhere, it attracts my attention

Well, things like a 5 times faster page rendering sounds awesome. Let's wait till the upgrade/migrate process is more clear.

[David Jiménez, modificado 15 Anos atrás.]

Hello,

I'm trying upgrade to LR 5.1.0. Now I have LR 5.0.1 in production and it's working properly.
I see different problems in the upgrading to LF 5.1.0 and I decide to build LR using the trunk code. In the version 18598 the database upgrade seem work, because in other versions I had to upgrade database manually, but It's produced the next error log. In jira (http://support.liferay.com/browse/LEP-6772) I have seen this problem had been corrected. Is it correct?

Thank u.

12:14:13,559 ERROR [QuartzSchedulerEngineImpl:84] Unable to initialize engine
org.quartz.SchedulerConfigException: Failure occured during job recovery. [See nested exception: org.quartz.JobPersistenceException: Couldn't clean volatile data: ERROR: operator does not exist: character varying = boolean [See nested exception: org.postgresql.util.PSQLException: ERROR: operator does not exist: character varying = boolean]]
at org.quartz.impl.jdbcjobstore.JobStoreSupport.initialize(JobStoreSupport.java:557)
at org.quartz.impl.jdbcjobstore.JobStoreTX.initialize(JobStoreTX.java:59)
at org.quartz.impl.StdSchedulerFactory.instantiate(StdSchedulerFactory.java:1204)
at org.quartz.impl.StdSchedulerFactory.getScheduler(StdSchedulerFactory.java:1355)
at com.liferay.portal.scheduler.quartz.QuartzSchedulerEngineImpl.<init>(QuartzSchedulerEngineImpl.java:81)
at com.liferay.portal.scheduler.quartz.QuartzSchedulerEngineUtil.init(QuartzSchedulerEngineUtil.java:56)
at com.liferay.portal.events.GlobalStartupAction.run(GlobalStartupAction.java:225)
at com.liferay.portal.events.EventsProcessor._processEvent(EventsProcessor.java:167)
at com.liferay.portal.events.EventsProcessor._process(EventsProcessor.java:119)
at com.liferay.portal.events.EventsProcessor.process(EventsProcessor.java:55)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:422)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4364)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: org.quartz.JobPersistenceException: Couldn't clean volatile data: ERROR: operator does not exist: character varying = boolean [See nested exception: org.postgresql.util.PSQLException: ERROR: operator does not exist: character varying = boolean]
at org.quartz.impl.jdbcjobstore.JobStoreSupport.cleanVolatileTriggerAndJobs(JobStoreSupport.java:736)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$1.execute(JobStoreSupport.java:697)
at org.quartz.impl.jdbcjobstore.JobStoreSupport$40.execute(JobStoreSupport.java:3628)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3662)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.executeInNonManagedTXLock(JobStoreSupport.java:3624)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.cleanVolatileTriggerAndJobs(JobStoreSupport.java:693)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.initialize(JobStoreSupport.java:555)
... 37 more
Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: character varying = boolean
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1548)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1316)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:191)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:351)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:255)
at org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93)
at org.quartz.impl.jdbcjobstore.StdJDBCDelegate.selectVolatileTriggers(StdJDBCDelegate.java:3491)
at com.liferay.portal.scheduler.quartz.DynamicDriverDelegate.selectVolatileTriggers(DynamicDriverDelegate.java:567)
at org.quartz.impl.jdbcjobstore.JobStoreSupport.cleanVolatileTriggerAndJobs(JobStoreSupport.java:714)
... 43 more
12:14:13,563 ERROR [GlobalStartupAction:228] java.lang.NullPointerException
java.lang.NullPointerException
at com.liferay.portal.scheduler.quartz.QuartzSchedulerEngineImpl.start(QuartzSchedulerEngineImpl.java:193)
at com.liferay.portal.scheduler.quartz.QuartzSchedulerEngineUtil.init(QuartzSchedulerEngineUtil.java:58)
at com.liferay.portal.events.GlobalStartupAction.run(GlobalStartupAction.java:225)
at com.liferay.portal.events.EventsProcessor._processEvent(EventsProcessor.java:167)
at com.liferay.portal.events.EventsProcessor._process(EventsProcessor.java:119)
at com.liferay.portal.events.EventsProcessor.process(EventsProcessor.java:55)
at com.liferay.portal.servlet.MainServlet.init(MainServlet.java:422)
at javax.servlet.GenericServlet.init(GenericServlet.java:212)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1161)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4364)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626)
at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1147)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

[Bruno Farache, modificado 15 Anos atrás.]

Hi David, thank you for bringing this up again.

I just fixed it in revision 18619, after you update your code, remeber to run build-db to update your postgresql scirpt.

[satya panduga, modificado 15 Anos atrás.]

I had liferay 5.0 with permissions.user.check.algorithm=2 was working fine. I have installed 5.1 with the existing database it displays "You do not have permission to view this page" .As suggested i have downloaded the revision 18619, still the problem exist. I do know that if i change the algorithm back to 2 , it will work. But I would like it to work using algorithm=5 , which uses role based permissioning. On some thread i read that they are in the process of developing the database upgrade scripts to convert user based permissioning to role based permissioning. I do not think that is done in the revision 18619.

Please Advice.

Thanks
satya

[Ray Augé, modificado 15 Anos atrás.]

Unfortunately, the process is not yet developed. Only new deployments of
the portal should use [tt]permissions.user.check.algorithm=5[/tt] at
this time. Those which are migrations from previous versions must use
[tt]=2[/tt].

Sorry!

[Christian Steiger, modificado 15 Anos atrás.]

Hi Ray,
is there a timeline for the process to switch to the new permission checker when LPortal is migrated from an older verison (4.3.5)

Thanks
Christian

[Ray Augé, modificado 15 Anos atrás.]

Not as of yet.

I'm trying to get to it... but it's a big job, and I'm tasked out right
now.

Sorry!

[Alex Wallace, modificado 15 Anos atrás.]

My upgrade is from 4.3.1 to 5.1.x branch, and using the AdvncedPermissionChecker doesn't cut it... however the Simple one seems to work... Is this expected? Am i loosing something critical by using the Simple one?

I just did an svn update and see some update to AdvancedPermissionChecker... will check it out... If it starts working i'll comment it here...

Thanks!

[Gaspare Provenzano, modificado 15 Anos atrás.]

I have upgraded from LR 4.3.4 to 5.1.1.

I have set the properties:

permissions.checker=com.liferay.portal.security.permission.AdvancedPermissionChecker
permissions.user.check.algorithm=2

but I still cannot access the old communities and pages. I logged as an administrator, I saw all the communities in the "My Places" and in the "Community Portlet" but if I try to access to a page I remain on the login page.

If I create new communities and pages I can access to them. The problem is with old communities. I use Oracle and, at each startup, I see in the logs that LR starts the Upgrade process.

Every time I try to access to an "old" page I have these warnings:

15:40:40,812 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:40:40,812 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:40:40,953 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=53804}
15:40:40,953 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=53804}
15:40:41,593 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:40:41,593 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:40:41,625 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:40:41,640 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:40:41,765 INFO  [velocity:148] Null reference [template '/dash_SERVLET_CONTEX
T_/html/themes/_unstyled/templates/init.vm', line 1, column 1] : $theme_display.
getPathThemeTemplates() cannot be resolved.
15:40:41,812 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:40:41,828 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 182, column 9]
15:40:41,828 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 183, column 8]
15:40:41,828 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 184, column 8]
15:40:41,828 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:40:41,843 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:40:41,843 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:40:41,843 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:40:41,843 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 266, column 1]
15:40:41,906 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:40:42,203 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:40:42,203 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:21,515 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:54:21,515 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:54:21,671 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=53804}
15:54:21,671 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=53804}
15:54:21,796 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:54:21,796 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:54:21,843 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:54:21,859 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:54:22,015 INFO  [velocity:148] Null reference [template '/dash_SERVLET_CONTEX
T_/html/themes/_unstyled/templates/init.vm', line 1, column 1] : $theme_display.
getPathThemeTemplates() cannot be resolved.
15:54:22,093 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:22,093 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 182, column 9]
15:54:22,093 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 183, column 8]
15:54:22,093 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 184, column 8]
15:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:22,109 INFO  [velocity:148] RHS of #set statement is null. Context will no
t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
ine 266, column 1]
15:54:22,156 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
GroupId=108401}
15:54:22,656 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:22,671 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
xpected EOF in prolog
 at [row,col {unknown-source}]: [1,0]
15:54:23,062 WARN  [ImageServlet:157] Get a default image for 0

[Gaspare Provenzano, modificado 15 Anos atrás.]

I solved the issue. The problem is that the upgrade SQL scripts don't fill the required "friendlyurl" fields.

In order to fix the problem, I used these SQL lines:

update group_ set friendlyurl = concat('/', groupid) where friendlyurl is null;

update layout set friendlyurl = concat('/', layoutid) where friendlyurl is null;

commit;

Finally, if you want to be sure that LR don't try to upgrade the DB at each startup, and you feel confident that the upgrade was ok, you can set manually the DB version:

update release_ set buildnumber='5101', modifieddate=sysdate, verified = '1' where buildnumber='4304';

commit;

[Artur Linhart, modificado 15 Anos atrás.]

Hello, Gaspare and all,

I think I have found the real cause of the issue. Only to run the statements above will not help to have consistent liferay version. The only systematic solution for me was to disable scheduler before the conversion is started.

Before the upgrade the scheduler has to be turned off by the statement

scheduler.enabled=false

otherwise the problem occurs again (see the description of the error mechanism and how to avoid this in http://issues.liferay.com/browse/LPS-1003).

It is really very difficult to find the real cause for it and to simluate this error - if for example the upgrade is tested on a small database from 5.0.1 to 5.1.0 only, then it will be so fast, that the scheduler will not be fired... And the error would not occur. It occurs only if upgrading from more than one version before.

I hope this can help to somebody to spare some time :-). But as I have written in LPS-1003, this problem could be avoided by more changed setting, which - if my theory is correct - from my point of view all must be set like today to let this error occur.

cheers, Artur

P.S. In my case before disabling the scheduler the upgrade alway has failed with the exception

com.liferay.portal.kernel.events.ActionException: com.liferay.portal.upgrade.UpgradeException: org.postgresql.util.PSQLException: ERROR: relation "quartz_job_details" already exists

and has not been executed.

[Brian Scott Schupbach, modificado 14 Anos atrás.]

What happens if I've already run the update, am missing pages, and now want to restore them. (I've missed the part about setting the scheduler to false) are they just gone? can I update the DB in any way to get them back?

Thanks,

Brian

[Artur Linhart, modificado 14 Anos atrás.]

I would suggest to turn off the portal, restore the DB from the backup before the upgrade, change the portal settings as necessary and start the portal again.

If there is no backup before upgrade, then... OK, this would be a terrible situation - is it so?

with regards, Artur

[Brian Scott Schupbach, modificado 14 Anos atrás.]

yeah....it is too late for that at this point. What we've done is actually begun manually re-creating all the old pages. After we're done the plan is to use google web master tools to try and find any broken links that might still be out there. We've gone through thousands of pages....not very fun.

Thanks for the help though. I wish I would have known about this beforehand.

[Artur Linhart, modificado 14 Anos atrás.]

ok, it is a pretty bad situation.

But - I do not want to make You more nervous but - as far as I remember if the upgrade has been interrupted, then not only the conversion of the pages was incomplete, but also some other stuff remained unconverted in the DB. Also the portal started the conversion always again and again with every restart because the version has not been modified correctly after successfull upgrade in the corresponding Db table. Please, look into the logs if it is not also your problem.

If You have the backup, You could test the upgrade once again on some integration test infrastructure, if it still will not be better than to repair the broken data and hope there will come no other problems in the future. Of course the problem could be, if You already have the message board posts or other new articles or other new content put into the portal... :-( But from my point of view it would be less risky to put again the content of the last month into the DB if Youc an be sure the DB is in a good consistent state than now to invest a lot of effort into the repaires if You really do not know it solved Your problems for the future.

I am very surprised this error occured now - actually based on our research of the problems, in the version 5.2.x it has been repaired as far as I know so if You use the version 5.2.3 for the upgrade, then this problem should never occur. What was the version You used for the upgrade?

Generally, I do not know if there are written some best practices for the upgrade on the Liferay Wiki, but from our point of view it was an absolute must first to make the Db dump import into the integration test infrastructure and test the upgrade there. The simplest way how to establish the integration test infrastructure is to create a new server running on a different port than the productive one, but all other addresses would be the same like in the case of the productove server - then also the complex server structure with a lot of websites and own host names (virtual hosts), etc. will be functional, just differ by the port in all urls, what works immediatelly automatically (if You use relative urls within the articles etc).

Do You have the list of the problems which still occur (are visible) on Your portal? You should ignore no error in the logs, no strange behavior of the portal, etc.

[Brian Scott Schupbach, modificado 14 Anos atrás.]

ha...yeah, it wasn't a great situation. We spent the end of last week and this weekend re-creating pages, re-linking, and testing all of our communities. We've restarted the portal several times since the upgrade and actually haven't had any issues. My hope is that we don't run into the additional problems you've described. Thanks for the warning though...I'll keep an eye out. The version we have upgraded to is version 5.2.3. Thanks for the testing environment tips. We obviously need to create a better one if we missed this...

some errors I'm still receiving are

08:43:22,887 ERROR [LayoutImpl:208] com.liferay.portal.NoSuchLayoutException: No Layout exists with the key {groupId=1066685, privateLayout=false, layoutId=22}
com.liferay.portal.NoSuchLayoutException: No Layout exists with the key {groupId=1066685, privateLayout=false, layoutId=22}

com.liferay.portal.kernel.xml.DocumentException: Error on line -1 of document  : Premature end of file. Nested exception: Premature end of file.

08:51:00,945 ERROR [UploadServletRequestImpl:111] org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException: the request doesn't contain a multipart/form-data or multipart/mixed stream, content type header is null

org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException: the request doesn't contain a multipart/form-data or multipart/mixed stream, content type header is null

08:22:00,448 ERROR [[default]:260] Servlet.service() for servlet default threw exception
java.lang.StringIndexOutOfBoundsException: String index out of range: -1

05:23:04,643 WARN  [PortalImpl:2948] Current URL /c/journal/view_article_content?cmd=preview&groupId=1862&articleId=187366&version=1.0&languageId= generateexception: Error on line -1 of document  : Premature end of file. Nested exception: Premature end of file.
05:23:04,685 ERROR [jsp:1024] com.liferay.portal.kernel.xml.DocumentException: Error on line -1 of document  : Premature end of file. Nested exception: Preture end of file.
com.liferay.portal.kernel.xml.DocumentException: Error on line -1 of document  : Premature end of file. Nested exception: Premature end of file.
        at com.liferay.portal.xml.SAXReaderImpl.read(SAXReaderImpl.java:377)
        at com.liferay.portal.xml.SAXReaderImpl.read(SAXReaderImpl.java:365)
        at com.liferay.portal.xml.SAXReaderImpl.read(SAXReaderImpl.java:382)
        at com.liferay.portal.kernel.xml.SAXReaderUtil.read(SAXReaderUtil.java:150)
        at com.liferay.portlet.journal.action.ViewArticleContentAction.execute(ViewArticleCo

Thanks for your help!

[Artur Linhart, modificado 14 Anos atrás.]

Hello,

please, can You verify in the table "release_" there is only one row and in the field "buildnumber" there is the value 5203? If it is not so, then I guess the portal would start the upgrade always again and again... But I think this will be so, because otherwise you would not connect to the portal at all...

According to the errors:
1. "Error on line -1 of document" related stuff - I would guess there is some invalid tempalte processed during the creation of the article output. I have seen the message

/c/journal/view_article_content?cmd=preview&groupId=1862&articleId=187366&version=1.0&languageId= generateexception: Error on line -1 of document

- so I would verify the template of the article with articleid 187366 in the groupid 1862

2. according to "08:43:22,887 ERROR [LayoutImpl:208] com.liferay.portal.NoSuchLayoutException: No Layout exists with the key {groupId=1066685, privateLayout=false, layoutId=22}
2com.liferay.portal.NoSuchLayoutException: No Layout exists with the key {groupId=1066685, privateLayout=false, layoutId=22}"
- I would check the content of the column "typesettings" of the table "layoutset" by all such records, having the "type_" of the value "link_to_layout" - in the typesettings is then the group id and layout number - so the layout with the given group id, layoutid and privatelayout parameters has to exist, which are specified in the typesettings... Maybe possible something like

SELECT * from layoutset WHERE typesettings like "%groupId=1862%linkToLayoutId=22%"

could help You to identify the wrong layouts and their groups and then you can go into the protal and repair the link to layout there...

[AMIT KUMAR SINGH, modificado 12 Anos atrás.]

Michael Reiche:

Or put the important property from portal-legacy-5.0.properties:

permissions.user.check.algorithm=2

in the file:

webapps/ROOT/WEB-INF/classes/portal-ext.properties

which is read anyway

This worked and I could reassign the guest permissions. Thanks

[Rob Sonke, modificado 15 Anos atrás.]

I found out that the statements in the update script about Quartz weren't executed.

That has nothing to do with the new permission algorithm, does it?

[Josh Asbury, modificado 15 Anos atrás.]

Rob Sonke:

I found out that the statements in the update script about Quartz weren't executed.

That has nothing to do with the new permission algorithm, does it?

I will mess around with this later to see what this impacts. I'm on vacation this week, so it'll be a little catch as catch-can.

Josh

[Rainer Schmitz, modificado 15 Anos atrás.]

Josh Asbury:

Rob Sonke:

I found out that the statements in the update script about Quartz weren't executed.

That has nothing to do with the new permission algorithm, does it?

I will mess around with this later to see what this impacts. I'm on vacation this week, so it'll be a little catch as catch-can.

Josh

I had filed a Jira issue (including a workaround) for this. It's now fixed in trunk
See http://support.liferay.com/browse/LEP-6772

Rainer

[Rob Sonke, modificado 15 Anos atrás.]

Great, thanks!

[Arman L, modificado 15 Anos atrás.]

Here is how I switched to the new algorithm:

With my upgraded to 5.1.1 portal and permissions.user.check.algorithm=2 I did export all the communities.

Then I run a new instance of 5.1.1 portal on a clean DB and permissions.user.check.algorithm=5

I did import all the communities without importing the permissions.

My current site does not have many pages and content for now so it was easy to create new roles and apply the permissions according to the new role-based algorithm. The problem that I had was with the links to the image library in my articles because the IDs have different format. But again, since I did not have that much of a content, I was able to have a clear start in an hour. Another thing I noticed was during all the upgrades I lost the search functionality for some reason - the search was not able to find any pages. I fixed that by going to the pages and re-selecting the article in the jurnal content portlets. I gues that trigered something and registered the page/article information in the search mechanism.