Problem with overloaded JSONWebServices

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 6.0.12 EE, 6.1.0 CE RC1
• Fix Version/s: 6.0.12 EE, 6.1.0 CE RC1
• Component/s: API > Portal Service
• Labels: None
• Branch Version/s:
  6.0.x
• Backported to Branch:
  Committed
• Similar Issues: Show 3 results ; ;

  LPS-17278	Rename REST functionality to JSONWebService
  LPS-19137	Add JSONWebServices annotations from service builder
  LPS-14595	Allow portal jsps to be overloaded by theme templates

What is going on: we have 3 overloaded get-user-places methods. This is their sorted order:

1. GroupServiceUtil#getUserPlaces()
2. GroupServiceUtil#getUserPlaces(classNames, max)
3. GroupServiceUtil#getUserPlaces(userId, classNames, max)

when /group/get-user-places is invoked (no extra params) we aim for the first method (1), with zero arguments.

However, due to smart method arguments providing functionality, we have 'userId' set as well - this one comes from logged user. So JSONWebServiceActionsManagerImpl chooses method (3) over (1), since the most method arguments are matched.

[Igor Spasic]

Proposed fix does the following change:

Methods are being matched only if all method arguments are provided; either explicitly (req. parameters etc.) or as default (serviceContext, userId...).

In above example, method (3) is not going to be matched since only 'userId' is provided from all three method arguments.

[Igor Spasic]

The problem that was not addressed is sending null values. Up to now nulls were passed to all missing arguments i.e. to one that are not provided. This was not possible any more since last patch, since we now expect to fully provide all arguments, in order to match service method.

So new fix is needed to specify null arguments with '-' prefix. for example:
http://.../dlsync/get-d-l-sync-update/company-id/10151/repository-id/10195/-last-access-date/

this specifies that lastAccessDate is null.

[Igor Spasic]

Moreover, we will add method argument count hints that helps with matching.

If method hint is available, the best match method will be returned (i.e. as in previous version). So, if method hint is there, we will scan only methods with that number of arguments and we will not insist that all arguments are provided.

[Vicki Tsang]

This is being bulk closed in preparation for the new workflow.