New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Path semantics for pattern READ request should be changed #106
Comments
It would be nice if described behaviour could be implemented in some of next releases. I am preparing monitoring tool for couple of environments on WebSphere 7.0 and I found out that I can not use pattern read request. For example: Request:
Response: I do not want the whole structure of the response, so what I want to do is:
But it fails with:
On the other hand following request with full mbean name works fine:
I would like to use pattern requests instead of requests with full mbean names because it is easier to transfer to other environments and it is more readable too. |
Ok, let's see what I can do. I will try to get this into 1.1.5, however no promises when it will be ready, though ;-) (I will try to have a look this evening, but it can take some time until the next release, since I'm filled up with work quite heavily 😓 |
Seems to be more complicated to implement than expected so it won't make it to 1.2.1 either. Sorry. |
It will make it into 1.2.2, just have implememted 'wildcard' path parts and going to update the documentation accordingly. More on this later. |
So, it's finished so far. Quite complex beast, but I think it was worth because of the gained flexibility. In you case you can use
to get to the statistics entries only. Also I recommend to have an eye on https://github.com/rhuss/jolokia-extra which makes access to Websphere (or JSR-77 metrics in genenral) statistic informations much easier. The feature will be available in 1.2.2 to be released quite soon. |
When doing a pattern read request which results in multiple matches, then providing a path doesnt make much sense currently, since it applies on the whole map returned with the MBean names as keys in the first level (see the reference manual for details).
For homogenous reads on similar MBean it would make much more sense to apply the path only on the final value parts (for each MBean matched).
Since pathes are currently not usable with this sort of request, changing the behaviour shouldn't harm much so that it can be done within a minor release.
The text was updated successfully, but these errors were encountered: