Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
When sending read request via POST with a single Attribute and debug is true, request fails #305
How to create this bug?
Expected: The value of of the attribute returned in the response body.
I tracked the bug to JmxReadRequest:
The fixed code should be:
Also another bug here is that the status code returned is 200 although it's a bug. The reader has no way of telling whether to read a single JSON containing an error or a JSON Array of the result in case you request multiple read requests. The status code in this case should have been 500.
Agree to your analysis w.r.t to the attribute names, will fix that asap.
w.r.t to the HTTP status code, we take a bit a different approach then REST:
The reason for this is that you can have bulk requests where some JMX requests can succeed and some can fail.
This is also explained in the reference manual:
And as said, Jolokia is not REST. See also this Blog Post for some reasoning why not.
Sorry, was a bit too fast.
Actual the behaviour was correct, that when you use a list of attributes you should use a
JmxReadRequest is mostly an internal object anyway.
The bug actually is in the
Thanks for the very fast fix!
Regarding the status code explanation. I'm perfectly fine with your approach. The only problem I have with it is that I have no way to know when to read a JSON object vs a JSON array.
When I issue a read, I do this:
I expect the response to be an ArrayList.
But when the same request fails I do not get an array list but a JSON object.
If the response were always a JSON object containing a statusCode field and then a body field which contains the actual result I can do an if.
This is the example of correct result:
This is an example of the result in case of failure:
How do you recommend I will parse the body? How to know when to expect a JSON Object or an ARRAY?
Completely agreed that the JSON structure should not be different for success or not. And normally this is not different, but in this case, where an internal error occurred (which was a bug in the
For this case it should be fixed, but I will have a closer look whether it can be made even more bullet proof.
w.r.t to a release date: A 1.3.6 release is already overdue, so I will release one soon. But unfortunately I'm quite stacked with work so no promises. But I think this should happen until the end of next week.
Actually we should be quite save.
If you look at the loop over all requests you will see that everything within the executeRequest() method is guarded completely with catches, the only thing not catched in this loop over all requests it the debug statement. And actually this caused the trouble here. If this is safe (hope so now), then I don't expect any further issues w.r.t to the JSON response structure.