[OPENAM-6302] Upgrade incorrectly sets default value for the REST APIs service Created: 06/Jul/15  Updated: 05/Sep/16  Resolved: 01/Sep/15

Status: Resolved
Project: OpenAM
Component/s: rest, upgrade
Affects Version/s: 12.0.0, 12.0.1, 12.0.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Peter Major [X] (Inactive) Assignee: Ken Stubbings
Resolution: Not a defect Votes: 0
Labels: AME, EDISON, NEWTON, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to OPENAM-6301 JSON objects for error messages do no... Resolved
relates to OPENAM-6469 Documentation for the upgrade default... Resolved
Target Version/s:
Sprint: Sprint 90 - Team Newton


Having a look at:

suggests that the REST APIs service will be updated to use the "OLDEST" value for the openam-rest-apis-default-version configuration value, however the RestApis.xml that contains the service definition actually has value of "Oldest".
Unfortunately the difference in the casing means that the setting will have no value configured, which can later on cause confusing issues such as OPENAM-6301.

Comment by Peter Major [X] (Inactive) [ 06/Jul/15 ]

Workaround is to manually set the Default Version setting in the REST APIs service to the preferred value:

$ openam/bin/ssoadm set-attr-defs -s RestApisService -t Global -a openam-rest-apis-default-version=Latest -u amadmin -f .pass
Comment by Gene Hirayama [ 14/Jul/15 ]

Added to 12.0.1 Release Notes in the Limitations section.

Comment by Ken Stubbings [ 27/Jul/15 ]

I have been playing around with the settings for the open-rest-apis-default-version setting using the soma command. it appears there is no difference if you set the value to be Oldest or OLDEST, so I doubt changing the default in the RestApiUpgradeHelper from OLDEST to Oldest is going to make an observable change to behaviour.

I would guess from the expected behaviour expressed in OPENAM-6301 that the value in RestApiUpgradeHelper should be changed to "Latest", however I will go in search of some documentation to back this up.

Comment by Ken Stubbings [ 27/Jul/15 ]

I have been pointed to the documentation here: http://docs.forgerock.org/en/openam/12.0.0/admin-guide/index/chap-rest.html which states that the default for a updated instance is Oldest. This is the observed behaviour (and the value has been found to be case insensitive) so this might not be a bug.

However the behaviour of the system as currently described is a little unusual. if version 12.0.0 of openam is installed then the value for the default api will be Latest and the api version used will be 12.0.0. If an upgrade is performed to version 13.0.0 of openam then system upgrade process will set the value to oldest and the default api will become 11.0.0.

Comment by Ken Stubbings [ 27/Jul/15 ]

Discussed with Neil Madden - desired behaviour is:

  • during first time installation set the default to be Latest
  • during upgrade if the property already exists use the existing configured value
  • if the property was not found set the value to be Oldest

This will require an update to the documentation for 13.0.0 as well.

Comment by Ken Stubbings [ 28/Jul/15 ]

Upon closer examination of the code it appears that this is implemented as above. If the value already exists during upgrade the existing value will not be edited.

Comment by Ken Stubbings [ 28/Jul/15 ]

The variable default value has been changed from "OLDEST" to "Oldest". Although it should be noted that this change will not have a functional impact. Please see the other notes and referenced documentation enhancement.

Comment by Peter Major [X] (Inactive) [ 01/Sep/15 ]

If I understand correctly this issue occurs because the default API versioning behavior is OLDEST, and as such the REST API responses will be in the old format and not in the LATEST format, this is why the response differs between a fresh installation and an upgraded deployment.
As such this is not a defect.

Generated at Tue Oct 27 04:04:13 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.