500 error on getJobDetails quartz

[jblayneyXpanxion]

Hey there, I don't have time to fix this so I figured I'd log some issues I found and some enhancement requests.

Calling /jobDetails/{quartzGroupName}/{quartzJobName}

For a job that doesn't exist returns a 500 error. I found the line it throws in the past, but can't recall - its pretty obvious - I think there is a filter that runs, then it calls .get(0) on the resulting structure which is empty, so it throws.

Also, {quartzGroupName} should now be made optional, and default to null. Internally, null will use the QuartzDefaultGroup, so if unspecified in the API/swagger would default to null=defaultGroup.

Ideally the API would return 404 with a response body indicating if the quartzGroupName was not found or if the quartzJobName was not found.

[chrisgleissner]

Hi, Thanks for the heads up. I will have a look at the points you raised. In terms of the rest api, what do you think about passing in 'default' as the group name in case one refers to the default quartz group name? Thanks Chris

…

On Thu, Jun 4, 2020, 20:04 jblayneyXpanxion ***@***.***> wrote: Hey there, I don't have time to fix this so I figured I'd log some issues I found and some enhancement requests. Calling /jobDetails/{quartzGroupName}/{quartzJobName} For a job that doesn't exist returns a 500 error. I found the line it throws in the past, but can't recall - its pretty obvious - I think there is a filter that runs, then it calls .get(0) on the resulting structure which is empty, so it throws. Also, {quartzGroupName} should now be made optional, and default to null. Internally, null will use the QuartzDefaultGroup, so if unspecified in the API/swagger would default to null=defaultGroup. Ideally the API would return 404 with a response body indicating if the quartzGroupName was not found or if the quartzJobName was not found. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#17>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA6JA66Q77UOD3DNRXJXFLTRU7O2JANCNFSM4NS3N7CA> .

[jblayneyXpanxion]

Good point, since the group name is on the uri you can't really make it blank. I like using "default" for that.

A couple other thoughts to add if you're open to more ideas. Both may / may-not be manageable:

• If its possible to get a list of registered quartz groups, this could be handled internally and endpoint changed to /jobDetails/{quartzJobName} - where the job name is internally searched within each registered quartz group.
• Could also change the group and job name to a single resource within the uri - for example:
  /jobDetails/{quartzGroupName}:{quartzJobName} would be used to specify the group - eg: /jobDetails/default:{quartzJobName} would be equal or a subset-lookup similar to /jobDetails/quartzJobName. This sort of endpoint might enable making group name optional, when unspecified the service would handle trying to find the job within registered quartz groups.

[chrisgleissner]

Hi,

thanks for the two suggestions in your last post, good ideas. And this would also ensure backwards compatibility of the API. I've been quite busy so have not yet had the chance to work on this.

Thanks