JS: Allow the possibility for providing query options when using jolokia.register()

[rhuss]

Currently it is not possible to provide processing options (transported via query options) when using j4p.register(...) in the JavaScript client. In this case, processing options can only be given to constructor of the Jolokia client. One could use individual client objects with different processing options, but this is an overhead which can be avoided when allowing processing options directly when registering jobs.

See also #61 for a former discussion with the same issue.

[rhuss]

I should have read #61 more closely ;-). Providing individual options for register() doesnt work easily because all scheduled requests are sent together in a single bulk requests sharing the same options. A solution would be to allow options within the request object itself, overriding options given as query parameters (will work for POST only, though).

The alternative to split the bulk requests for different options given in register() is not very useful because of the complexity and undetermined runtime behaviour (whether 1 or 2 or 3 ... HTTP requests are sent is not transparent).

[rhuss]

Since for bulk requests each single request should be able to have individual processing options. The best way to implenent this is to add a options key to the request which will override processing parameters given as query parameter to the request. This would also help especially the new ifModifiedSince #77 feature so that list requests can be packed up within bulk requests e.g. within the JavaScript scheduler.

The JavaScript API must also be adapted to allow request based options when registering requests as jobs.

[rhuss]

Well, config is already supported for POST JSON requests. Forget that already, was some time agog ;-). (so you can override query parameters with a dedicated config option in the request). This is also already documented. However support for the JS scheduler can be better (up to now, you can add simply config to the request which is registered as job) and I will add the possibility to register the configuration params explicitely when registering a job.

I'm getting old ;-) 👴