Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
5.1.0 Upgrade Problem Joshua Asbury July 18, 2008 5:02 AM
RE: 5.1.0 Upgrade Problem Rob Sonke July 18, 2008 12:41 PM
RE: 5.1.0 Upgrade Problem JR Houn July 18, 2008 1:44 PM
RE: 5.1.0 Upgrade Problem Michael Reiche July 19, 2008 3:12 AM
RE: 5.1.0 Upgrade Problem Joshua Asbury July 21, 2008 7:29 AM
RE: 5.1.0 Upgrade Problem Rob Sonke July 21, 2008 9:59 AM
RE: 5.1.0 Upgrade Problem Thomas Kellerer July 25, 2008 6:54 AM
RE: 5.1.0 Upgrade Problem Ray Augé July 25, 2008 11:31 AM
RE: 5.1.0 Upgrade Problem Rob Sonke July 26, 2008 1:11 AM
RE: 5.1.0 Upgrade Problem David Jiménez July 28, 2008 4:51 AM
RE: 5.1.0 Upgrade Problem Bruno Farache July 28, 2008 9:48 AM
RE: 5.1.0 Upgrade Problem satya panduga August 18, 2008 9:13 AM
Re: [Liferay Forums][1. Installation / Deployment / Setup] RE: 5.1.0 Upgrad Ray Augé August 18, 2008 6:52 PM
RE: Re: [Liferay Forums][1. Installation / Deployment / Setup] RE: 5.1.0 Christian Steiger September 8, 2008 1:09 AM
RE: Re: [Liferay Forums][1. Installation / Deployment / Setup] RE: 5.1.0 Ray Augé September 8, 2008 8:27 AM
RE: 5.1.0 Upgrade Problem Alex Wallace October 1, 2008 7:25 AM
RE: 5.1.0 Upgrade Problem Gaspare Provenzano October 1, 2008 8:53 AM
RE: 5.1.0 Upgrade Problem Gaspare Provenzano October 13, 2008 2:28 AM
RE: 5.1.0 Upgrade Problem Artur Linhart December 18, 2008 8:26 AM
RE: 5.1.0 Upgrade Problem Brian Scott Schupbach March 18, 2010 12:20 PM
RE: 5.1.0 Upgrade Problem Artur Linhart March 19, 2010 10:46 AM
RE: 5.1.0 Upgrade Problem Brian Scott Schupbach March 19, 2010 12:16 PM
RE: 5.1.0 Upgrade Problem Artur Linhart March 20, 2010 4:04 AM
RE: 5.1.0 Upgrade Problem Brian Scott Schupbach March 22, 2010 6:58 AM
RE: 5.1.0 Upgrade Problem Artur Linhart March 25, 2010 1:25 AM
RE: 5.1.0 Upgrade Problem AMIT KUMAR SINGH April 25, 2012 10:05 AM
RE: 5.1.0 Upgrade Problem Rob Sonke July 20, 2008 2:34 AM
RE: 5.1.0 Upgrade Problem Joshua Asbury July 21, 2008 7:34 AM
RE: 5.1.0 Upgrade Problem Rainer Schmitz July 22, 2008 12:25 AM
RE: 5.1.0 Upgrade Problem Rob Sonke July 22, 2008 12:40 AM
RE: 5.1.0 Upgrade Problem - My way of doing it Arman L August 22, 2008 10:20 AM
Joshua Asbury
5.1.0 Upgrade Problem
July 18, 2008 5:02 AM
Answer

Joshua Asbury

LIFERAY STAFF

Rank: Expert

Posts: 497

Join Date: September 8, 2006

Recent Posts

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
RE: 5.1.0 Upgrade Problem
July 18, 2008 12:41 PM
Answer

Rob Sonke

Rank: Expert

Posts: 275

Join Date: August 26, 2007

Recent Posts

Exact the same problem over here

I'll look into the update sql script in the next days.
JR Houn
RE: 5.1.0 Upgrade Problem
July 18, 2008 1:44 PM
Answer

JR Houn

LIFERAY STAFF

Rank: Expert

Posts: 489

Join Date: November 19, 2007

Recent Posts

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


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

-jr
Michael Reiche
RE: 5.1.0 Upgrade Problem
July 19, 2008 3:12 AM
Answer

Michael Reiche

Rank: New Member

Posts: 22

Join Date: January 14, 2007

Recent Posts

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
Rob Sonke
RE: 5.1.0 Upgrade Problem
July 20, 2008 2:34 AM
Answer

Rob Sonke

Rank: Expert

Posts: 275

Join Date: August 26, 2007

Recent Posts

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?
Joshua Asbury
RE: 5.1.0 Upgrade Problem
July 21, 2008 7:29 AM
Answer

Joshua Asbury

LIFERAY STAFF

Rank: Expert

Posts: 497

Join Date: September 8, 2006

Recent Posts

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!
Joshua Asbury
RE: 5.1.0 Upgrade Problem
July 21, 2008 7:34 AM
Answer

Joshua Asbury

LIFERAY STAFF

Rank: Expert

Posts: 497

Join Date: September 8, 2006

Recent Posts

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
Rob Sonke
RE: 5.1.0 Upgrade Problem
July 21, 2008 9:59 AM
Answer

Rob Sonke

Rank: Expert

Posts: 275

Join Date: August 26, 2007

Recent Posts

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
Rainer Schmitz
RE: 5.1.0 Upgrade Problem
July 22, 2008 12:25 AM
Answer

Rainer Schmitz

Rank: New Member

Posts: 19

Join Date: November 9, 2005

Recent Posts

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
RE: 5.1.0 Upgrade Problem
July 22, 2008 12:40 AM
Answer

Rob Sonke

Rank: Expert

Posts: 275

Join Date: August 26, 2007

Recent Posts

Great, thanks!
Thomas Kellerer
RE: 5.1.0 Upgrade Problem
July 25, 2008 6:54 AM
Answer

Thomas Kellerer

Rank: Expert

Posts: 377

Join Date: June 9, 2008

Recent Posts

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é
RE: 5.1.0 Upgrade Problem
July 25, 2008 11:31 AM
Answer

Ray Augé

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1195

Join Date: February 7, 2005

Recent Posts

Hello All,

About migrating from the original permission algorithm (permissions.user.check.algorithm=2) to the new algorithm (permissions.user.check.algorithm=5), 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:

1    permissions.checker=com.liferay.portal.security.permission.AdvancedPermissionChecker
2    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
RE: 5.1.0 Upgrade Problem
July 26, 2008 1:11 AM
Answer

Rob Sonke

Rank: Expert

Posts: 275

Join Date: August 26, 2007

Recent Posts

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

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
RE: 5.1.0 Upgrade Problem
July 28, 2008 4:51 AM
Answer

David Jiménez

Rank: New Member

Posts: 2

Join Date: December 26, 2007

Recent Posts

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
RE: 5.1.0 Upgrade Problem
July 28, 2008 9:48 AM
Answer

Bruno Farache

LIFERAY STAFF

Rank: Liferay Master

Posts: 573

Join Date: May 14, 2007

Recent Posts

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
RE: 5.1.0 Upgrade Problem
August 18, 2008 9:13 AM
Answer

satya panduga

Rank: New Member

Posts: 7

Join Date: July 21, 2008

Recent Posts

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é
Re: [Liferay Forums][1. Installation / Deployment / Setup] RE: 5.1.0 Upgrad
August 18, 2008 6:52 PM
Answer

Ray Augé

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1195

Join Date: February 7, 2005

Recent Posts

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

Sorry! emoticon
Attachment

Attachments: stock_smiley-4.png (0.9k)
Arman L
RE: 5.1.0 Upgrade Problem - My way of doing it
August 22, 2008 10:20 AM
Answer

Arman L

Rank: Junior Member

Posts: 27

Join Date: April 26, 2007

Recent Posts

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.
Christian Steiger
RE: Re: [Liferay Forums][1. Installation / Deployment / Setup] RE: 5.1.0
September 8, 2008 1:09 AM
Answer

Christian Steiger

Rank: New Member

Posts: 12

Join Date: November 13, 2007

Recent Posts

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é
RE: Re: [Liferay Forums][1. Installation / Deployment / Setup] RE: 5.1.0
September 8, 2008 8:27 AM
Answer

Ray Augé

LIFERAY STAFF

Rank: Liferay Legend

Posts: 1195

Join Date: February 7, 2005

Recent Posts

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
RE: 5.1.0 Upgrade Problem
October 1, 2008 7:25 AM
Answer

Alex Wallace

Rank: Liferay Master

Posts: 640

Join Date: November 4, 2007

Recent Posts

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
RE: 5.1.0 Upgrade Problem
October 1, 2008 8:53 AM
Answer

Gaspare Provenzano

Rank: Junior Member

Posts: 27

Join Date: June 6, 2007

Recent Posts

I have upgraded from LR 4.3.4 to 5.1.1.

I have set the properties:
1permissions.checker=com.liferay.portal.security.permission.AdvancedPermissionChecker
2permissions.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:

  115:40:40,812 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
  2GroupId=108401}
  315:40:40,812 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
  4GroupId=108401}
  515:40:40,953 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
  6GroupId=53804}
  715:40:40,953 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
  8GroupId=53804}
  915:40:41,593 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 10GroupId=108401}
 1115:40:41,593 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 12GroupId=108401}
 1315:40:41,625 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 14GroupId=108401}
 1515:40:41,640 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 16GroupId=108401}
 1715:40:41,765 INFO  [velocity:148] Null reference [template '/dash_SERVLET_CONTEX
 18T_/html/themes/_unstyled/templates/init.vm', line 1, column 1] : $theme_display.
 19getPathThemeTemplates() cannot be resolved.
 2015:40:41,812 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 21xpected EOF in prolog
 22 at [row,col {unknown-source}]: [1,0]
 2315:40:41,828 INFO  [velocity:148] RHS of #set statement is null. Context will no
 24t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
 25ine 182, column 9]
 2615:40:41,828 INFO  [velocity:148] RHS of #set statement is null. Context will no
 27t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
 28ine 183, column 8]
 2915:40:41,828 INFO  [velocity:148] RHS of #set statement is null. Context will no
 30t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
 31ine 184, column 8]
 3215:40:41,828 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 33xpected EOF in prolog
 34 at [row,col {unknown-source}]: [1,0]
 3515:40:41,843 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 36xpected EOF in prolog
 37 at [row,col {unknown-source}]: [1,0]
 3815:40:41,843 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 39xpected EOF in prolog
 40 at [row,col {unknown-source}]: [1,0]
 4115:40:41,843 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 42xpected EOF in prolog
 43 at [row,col {unknown-source}]: [1,0]
 4415:40:41,843 INFO  [velocity:148] RHS of #set statement is null. Context will no
 45t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
 46ine 266, column 1]
 4715:40:41,906 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 48GroupId=108401}
 4915:40:42,203 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 50xpected EOF in prolog
 51 at [row,col {unknown-source}]: [1,0]
 5215:40:42,203 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 53xpected EOF in prolog
 54 at [row,col {unknown-source}]: [1,0]
 5515:54:21,515 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 56GroupId=108401}
 5715:54:21,515 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 58GroupId=108401}
 5915:54:21,671 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 60GroupId=53804}
 6115:54:21,671 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 62GroupId=53804}
 6315:54:21,796 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 64GroupId=108401}
 6515:54:21,796 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 66GroupId=108401}
 6715:54:21,843 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 68GroupId=108401}
 6915:54:21,859 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
 70GroupId=108401}
 7115:54:22,015 INFO  [velocity:148] Null reference [template '/dash_SERVLET_CONTEX
 72T_/html/themes/_unstyled/templates/init.vm', line 1, column 1] : $theme_display.
 73getPathThemeTemplates() cannot be resolved.
 7415:54:22,093 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 75xpected EOF in prolog
 76 at [row,col {unknown-source}]: [1,0]
 7715:54:22,093 INFO  [velocity:148] RHS of #set statement is null. Context will no
 78t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
 79ine 182, column 9]
 8015:54:22,093 INFO  [velocity:148] RHS of #set statement is null. Context will no
 81t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
 82ine 183, column 8]
 8315:54:22,093 INFO  [velocity:148] RHS of #set statement is null. Context will no
 84t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
 85ine 184, column 8]
 8615:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 87xpected EOF in prolog
 88 at [row,col {unknown-source}]: [1,0]
 8915:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 90xpected EOF in prolog
 91 at [row,col {unknown-source}]: [1,0]
 9215:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 93xpected EOF in prolog
 94 at [row,col {unknown-source}]: [1,0]
 9515:54:22,109 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
 96xpected EOF in prolog
 97 at [row,col {unknown-source}]: [1,0]
 9815:54:22,109 INFO  [velocity:148] RHS of #set statement is null. Context will no
 99t be modified. /dash_SERVLET_CONTEXT_/html/themes/_unstyled/templates/init.vm [l
100ine 266, column 1]
10115:54:22,156 WARN  [GroupPersistenceImpl:340] No Group exists with the key {live
102GroupId=108401}
10315:54:22,656 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
104xpected EOF in prolog
105 at [row,col {unknown-source}]: [1,0]
10615:54:22,671 WARN  [LocalizationUtil:128] com.ctc.wstx.exc.WstxEOFException: Une
107xpected EOF in prolog
108 at [row,col {unknown-source}]: [1,0]
10915:54:23,062 WARN  [ImageServlet:157] Get a default image for 0
Gaspare Provenzano
RE: 5.1.0 Upgrade Problem
October 13, 2008 2:28 AM
Answer

Gaspare Provenzano

Rank: Junior Member

Posts: 27

Join Date: June 6, 2007

Recent Posts

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:

1update group_ set friendlyurl = concat('/', groupid) where friendlyurl is null;
2
3update layout set friendlyurl = concat('/', layoutid) where friendlyurl is null;
4
5commit;



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:

1update release_ set buildnumber='5101', modifieddate=sysdate, verified = '1' where buildnumber='4304';
2
3commit;
Artur Linhart
RE: 5.1.0 Upgrade Problem
December 18, 2008 8:26 AM
Answer

Artur Linhart

Rank: Expert

Posts: 458

Join Date: September 13, 2007

Recent Posts

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
RE: 5.1.0 Upgrade Problem
March 18, 2010 12:20 PM
Answer

Brian Scott Schupbach

Rank: Expert

Posts: 329

Join Date: October 23, 2008

Recent Posts

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
RE: 5.1.0 Upgrade Problem
March 19, 2010 10:46 AM
Answer

Artur Linhart

Rank: Expert

Posts: 458

Join Date: September 13, 2007

Recent Posts

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
RE: 5.1.0 Upgrade Problem
March 19, 2010 12:16 PM
Answer

Brian Scott Schupbach

Rank: Expert

Posts: 329

Join Date: October 23, 2008

Recent Posts

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
RE: 5.1.0 Upgrade Problem
March 20, 2010 4:04 AM
Answer

Artur Linhart

Rank: Expert

Posts: 458

Join Date: September 13, 2007

Recent Posts

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
RE: 5.1.0 Upgrade Problem
March 22, 2010 6:58 AM
Answer

Brian Scott Schupbach

Rank: Expert

Posts: 329

Join Date: October 23, 2008

Recent Posts

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

108: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}


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


108: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


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



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


105: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.
205: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.
3com.liferay.portal.kernel.xml.DocumentException: Error on line -1 of document  : Premature end of file. Nested exception: Premature end of file.
4        at com.liferay.portal.xml.SAXReaderImpl.read(SAXReaderImpl.java:377)
5        at com.liferay.portal.xml.SAXReaderImpl.read(SAXReaderImpl.java:365)
6        at com.liferay.portal.xml.SAXReaderImpl.read(SAXReaderImpl.java:382)
7        at com.liferay.portal.kernel.xml.SAXReaderUtil.read(SAXReaderUtil.java:150)
8        at com.liferay.portlet.journal.action.ViewArticleContentAction.execute(ViewArticleCo


Thanks for your help!
Artur Linhart
RE: 5.1.0 Upgrade Problem
March 25, 2010 1:25 AM
Answer

Artur Linhart

Rank: Expert

Posts: 458

Join Date: September 13, 2007

Recent Posts

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
RE: 5.1.0 Upgrade Problem
April 25, 2012 10:05 AM
Answer

AMIT KUMAR SINGH

Rank: New Member

Posts: 10

Join Date: March 28, 2012

Recent Posts

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