Open mranile-dev opened 1 month ago
We think that 1) is possible, and hopefully not too hard to implement. 2) is pretty hard because Quartz supports multiple trigger types.
I've worked a little bit on this issue, especially the trigger job on demand part. I've prototyped some changes in my branch.
To trigger a job on demand, overall does not require a lot of changes and can be implemented, but it requires some changes in AbstractWebFluxEndpointHandlerMapping
and AbstractWebMvcEndpointHandlerMapping
since both of them do not support Map<String, Object>
as an endpoint parameter. (Consider as a bug? By the way, Jersey works fine)
To support Map<String, Object>
as an endpoint parameter the following should be changed
in both classes:
@RequestBody(required = false) Map<String, String> body
should be changed to @RequestBody(required = false) Map<String, Object> body
, otherwise the following exception will be thrown:
[org.springframework.http.converter.HttpMessageNotReadableException:
JSON parse error: Cannot deserialize value of type `java.lang.String` from Object value (token `JsonToken.START_OBJECT`)]
Regarding the ability to override or update the existing trigger of the specific job. I am
not sure whether it is worth supporting this at all. For example, I checked the QuartzSchedulerMBean
interface and it does not have such functionality for JMX, at least I haven't found it. Overall, it could be implemented, but it requires a quite significant piece of work.
Let's implement capability #1 for now if it's doable. It will be a good feature for remotely triggering the job on-demand without waiting on the next scheduled trigger. Thanks @nosan Cheers!
Currently, SB is having actuator endpoints to retrieve details of Quartz scheduled jobs and its triggers. This feature request is to extend the actuators capability to be able to do the following: