com.liferay.portal.convert.ConvertPermissionAlgorithm - java.lang.ArrayIndexOutOfBoundsException: 0

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 5.1.2, 5.2.3, 6.0.4 GA
• Fix Version/s: 6.0.4 GA, 6.0.5 GA
• Component/s: Core Infrastructure > Upgrade Framework
• Labels: None
• Environment: Liferay 5.2.3 with Derby DB ; Upgraded several times (started with Liferay 3.6.x)
• Branch Version/s:
  5.1.x, 5.2.x, 6.0.x
• Backported to Branch:
  Committed
• Liferay Contributor's Agreement:
  Accept
• Similar Issues: Show 5 results ; ;

  LPS-20081	Classic Uploader in Document Library throws exceptions in console with 0 byte upload
  LPS-4494	ERROR [OpenSSOFilter] java.lang.ArrayIndexOutOfBoundsException
  LPS-12626	CLONE -ERROR [OpenSSOFilter] java.lang.ArrayIndexOutOfBoundsException
  LPS-1674	Setting lucene.store.type=jdbc in portal-ext.properties results in - java.lang.ArrayIndexOutOfBoundsException
  LPS-18464	ArrayIndexOutOfBoundsException: 0

This happend as I tried to upgrade the permission algorithm from 2 to 5/6 on a long running portal installation.

INFO | jvm 1 | 2010/03/18 13:00:43 | 2010-03-18 13:00:43,036 FATAL [liferay/convert_process:] com.liferay.portal.convert.ConvertPermissionAlgorithm - java.lang.ArrayIndexOutOfBoundsException: 0
INFO | jvm 1 | 2010/03/18 13:00:43 | java.lang.ArrayIndexOutOfBoundsException: 0
INFO | jvm 1 | 2010/03/18 13:00:43 | at com.liferay.portal.convert.ConvertPermissionAlgorithm._convertToBitwise(ConvertPermissionAlgorithm.java:176)
INFO | jvm 1 | 2010/03/18 13:00:43 | at com.liferay.portal.convert.ConvertPermissionAlgorithm.doConvert(ConvertPermissionAlgorithm.java:125)
INFO | jvm 1 | 2010/03/18 13:00:43 | at com.liferay.portal.convert.ConvertProcess.convert(ConvertProcess.java:41)
INFO | jvm 1 | 2010/03/18 13:00:43 | at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.doReceive(ConvertProcessMessageListener.java:59)
INFO | jvm 1 | 2010/03/18 13:00:43 | at com.liferay.portal.convert.messaging.ConvertProcessMessageListener.receive(ConvertProcessMessageListener.java:44)
INFO | jvm 1 | 2010/03/18 13:00:43 | at com.liferay.portal.kernel.messaging.InvokerMessageListener.receive(InvokerMessageListener.java:70)
INFO | jvm 1 | 2010/03/18 13:00:43 | at com.liferay.portal.kernel.messaging.SerialDestination$1.run(SerialDestination.java:54)
INFO | jvm 1 | 2010/03/18 13:00:43 | at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
INFO | jvm 1 | 2010/03/18 13:00:43 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
INFO | jvm 1 | 2010/03/18 13:00:43 | at java.lang.Thread.run(Unknown Source)

[Tobias Kaefer]

With this patch the Exception should not be thrown

— portal/portal-impl/src/com/liferay/portal/convert/ConvertPermissionAlgorithm.java 2009-08-19 11:56:43.000000000 +0200
+++ ext/ext-impl/src/com/liferay/portal/convert/ConvertPermissionAlgorithm.java 2010-03-18 14:13:21.000000000 +0100
@@ -173,6 +173,7 @@
while (Validator.isNotNull(line = resourceNameReader.readLine())) {
String[] values = StringUtil.split(line);

+ if(values.length > 0)

{ String name = values[0]; List<String> defaultActionIds = @@ -184,6 +185,8 @@ _convertResourcePermission(resourcePermissionWriter, name); }

+ }
+
resourcePermissionWriter.close();

MaintenanceUtil.appendStatus("Updating ResourcePermission table");

[Urvancev Andrey]

I have this issue in 6.0.4GA. After apply this patch, process of permissions converting was succefuly ended.
But when I change permissions.user.check.algorithm to 6 an restart portal. I can't login, can't see any page, because I'm get this message "You do not have permission to view this page."

[Urvancev Andrey]

And I see many warning messages in log files - "[ConvertPermissionAlgorithm] Could nof find resource action for.....". I think convertion process in this case reset permissions to 0. And nobody can't access to resource instead Administrator(who can't login to portal).

[Tobias Kaefer]

@Urvancev Andrey:
That is very strange.
We do have at least two LR portals running (currently 5.2.3). Both have gone through the permission conversion and none of them has ever had any kind of problem by using the 6 permission algorithm (bitwise algorithm).
These portals run with the bitwise algorithm for quite a while.

Our portals have been upgraded several times (starting from 3.6.x) and used before the conversion the algorithm 2.

Do you upgrade your portal from an earlier version of LR (which version)? Which "permissions.user.check.algorithm" did you use before?

[Urvancev Andrey]

I'm use last community edition version of 5.2 branch from svn.
Now portal use 5 permissions check algorithm.

[Anton Finders]

Same error. We are converting from 5.2.3 to 6..0.4.
In our case table 'resourcecode' contains 4 entries with name is empty. After deleting them the convertn works fine.
I'm not sure if those 4 entries are really needed anywhere.

[Alexander Chow]

@Tobias / @Anton I'm curious as to why you guys are having this problem. Do both of you have a line in the temp file with just a comma?

@Urvancev Are you saying you were running 5.2 with permission algorithm 5 and then you did the conversion to 6? Do you get a blank when you do query the ResourceCode table:

SELECT name FROM ResourceCode GROUP BY name

[Urvancev Andrey]

>>Do you get a blank when you do query the ResourceCode
Yes, blank string present.

[Urvancev Andrey]

>>have a line in the temp file with just a comma?
I'm have.

[Tobias Kaefer]

> @Tobias / @Anton I'm curious as to why you guys are having this problem. Do both of you have a line in the temp file with just a comma?
Yes. It seems so.
But I started this issue over a year ago, so I don't have the database that caused this Exception available (too bad, I know).

[Alexander Chow]

@Urvancev And you were running 5.2 w/ permission 5, upgraded to 6, then executed this conversion?

[Urvancev Andrey]

>>But when I change permissions.user.check.algorithm to 6 an restart portal. I can't login, can't see any page, because I'm get this message "You do not have permission to view this page."

[Alexander Chow]

OK, the patch has been committed to SVN trunk. It basically fixes the bug for everybody other than Urvancev. The "name" field in ResourceCode is meant to indicate the ID of the resource (portlet ID or model name). I am not sure why your environments have a blank "name" field; my only guess is you had some kind of custom code that was creating permissions for something without passing in a valid name.

Urvancev, your problem is somewhat different from everybody else and requires a bit more debugging. Please open a new ticket with more details of your environment. In particular, things like what kind of customizations were done to your system and whether you selected to generate the custom roles (default is to NOT generate them, so I would suggest you enable this and try again). Hope that helps.

[Brian Chan]

Thx Alex