[OPENAM-6374] Registering UMA resource sometimes gives error Created: 13/Jul/15  Updated: 15/Dec/15  Resolved: 05/Aug/15

Status: Resolved
Project: OpenAM
Component/s: UMA
Affects Version/s: 13.0.0
Fix Version/s: 13.0.0

Type: Bug Priority: Major
Reporter: Jamie Cavanaugh [X] (Inactive) Assignee: James Phillpotts
Resolution: Fixed Votes: 0
Labels: AME, TESLA, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Centos 7.1
Tomcat 7
Oracle Java 8
Happens on both development PCs and AWS environment

Attachments: File catalina.out     File debug.tar.gz     Zip Archive logs-20150716.zip    
Sprint: Sprint 89 - Team Tesla, Sprint 90 - Team Tesla, Sprint 91 - Team Tesla


When making a register resource request like below, an error is sometimes returned:


curl -sS \
--insecure \
--request POST \
--header "Authorization: Bearer ${PAT}" \
--data \
"name" : "'${NAME}'",
"icon_uri" : "http://www.example.com/icons/flower.png",
"scopes" : [
"type" : "http://www.example.com/rsets/photoalbum"
}' \



There is an exception in the Entitlement logs and in the Catalina log (see attached).

We are using OpenAM 13.0.0-SNAPSHOT Build 14532 (2015-July-09 03:09)

Once there is an error, there will always be an error. Restarting tomcat often resolves the issue. If there is a successful response, then there will usually be more successful responses. The error seems to happen most often after a re-deploy or restart.

It seems similar to an existing JIRA OPENAM-5786 but this has been marked as fixed.

Please let me know if you need more information

Comment by James Phillpotts [ 15/Jul/15 ]

It looks like this is happening when a policy engine Resource Type fails to be created for the UMA Resource Set (in AM we use one Resource Type per UMA RS, which are created when the RS is created). There's some missing exception catches in the UmaResourceSetRegistrationListener so hopefully more logging will be given when this does happen. Since adding that logging, I haven't experienced the problem again, so will commit the changes in case Jamie does experience it with a new nightly.

Comment by Tim Jacomb [X] (Inactive) [ 16/Jul/15 ]

We haven't had any problems with registering resources since getting the latest nightly build (2015-July-16)

A new issue seems to have been introduced though, we can now only share one resource ever.
If we try to share another resource then it responds with:

{"code":400,"reason":"Bad Request","message":"Invalid resource type d66337b3-ea43-4093-b486-6e1b79a34e371, must be one from the set defined against the containing application."}
Comment by Tim Jacomb [X] (Inactive) [ 16/Jul/15 ]

Attached some logs

Comment by Jamie Cavanaugh [X] (Inactive) [ 17/Jul/15 ]

Also, we get

{"code":500,"reason":"Internal Server Error","message":"java.lang.IllegalStateException cannot be cast to org.forgerock.json.resource.ResourceException"}

when trying to view the user's shares (e.g. /sso/XUI/#uma/resources/).

Are these related?

Edit for clairy Note this only occurs when using the 20150716 nightly build to see if the original error is fixed. Reverting back to the nightly build with the original error makes this error go away

Comment by James Phillpotts [ 04/Aug/15 ]

I finally got the original bug today again, and as it happens my colleagues in the policy engine had just fixed OPENAM-5821 which seems to have removed the issue, so I'm hoping this bug is now fixed.

Comment by James Phillpotts [ 05/Aug/15 ]

I'm resolving this issue as fixed as the root cause has been removed.

Generated at Mon Jan 25 04:28:51 UTC 2021 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.