jmx-dev JEP review : JDK-8171311 - REST APIs for JMX

Mon Sep 11 19:55:49 UTC 2017

> On Sep 11, 2017, at 9:46 PM, Martin Skarsaune <martin at skarsaune.net> wrote:
> 
> Hi Harsha and Erik
> 
> I certainly understand the desire to design the API well. 
> My point was just that when there is a mature battle-tested de-facto solution out in the wild,

I would agree that there are lessons to be learned from Jolokia. It is a great/useful tool but it is not a JMXConnector. IMHO the REST layer should be implemented as a JMXConnector. It is the implementation that has the ability to integrate with widest set of exiting tooling. 

Kind regards,
Kirk Pepperdine

> it would be a pity not to see potential for interoperability where the solutions are in fact really close. 
> To illustrate where I'm coming from, I hacked the source of a plugin that is able to control the flight recorder via JMX , to adapt the POST payloads to this JEP. 
> Assuming I understood it correctly the changes are quite small, but would the require a complete rewrite of all plugins, a layer of indirection or even worse a compatibility layer to use it. 
> Note: I assumed the arguments are still an array and not an object?  ([] , not {}) ?
> 
> You can see an example of what changes would typically be needed here:
> https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f <https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f>
> 
> Cheers
> 
> Martin
> 
> 
> man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine <kirk.pepperdine at gmail.com <mailto:kirk.pepperdine at gmail.com>>:
> Hi Harsha,
> 
> The only reason I mentioned Jolokia is that it’s a project that usefulness is some what limited because it is *not* a compliment JMX connector and as such cannot be used as a straight drop-in replacement for the current RMI based connector. Is your plan here to make it a fully compliant connector so that we could configure tooling such as the MBean viewers in jConsole and VisualVM (or JMC for that matter) to use a restful connector instead of an RMI based connector? IMHO, doing so would represent a huge win as I know of quite a few projects that cannot or will not use JMX because of it’s reliance on RMI.
> 
> Consolidating all of the options under a single flag looks like another interesting win.
> 
> Kind regards,
> Kirk
> 
> 
> 
>> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B <harsha.wardhana.b at oracle.com <mailto:harsha.wardhana.b at oracle.com>> wrote:
>> 
>> Hi Erik,
>> 
>> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote:
>>> Hi Harsha,
>>> 
>>> I haven't looked at Jolokia, or know what is the most reasonable approach in this case, but as a principle, I think we should strive for the best possible design rather than trying to be compatible with third party tools.
>> Agreed. That will always be the first priority. That is the reason HTTP GET interfaces will not be changed. I am undecided if the POST payloads need to be changed (without compromising the REST design principles) to increase adoption of this feature. 
>>> 
>>> How will the command line look like to start the agent with the rest adapter?
>>> 
>>> In the past there have been discussions about adding syntactic sugar for -Dcom.sun.management, i.e.
>>> 
>>> -Xmanagement:ssl=false,port=7091,authenticate=false
>>> 
>>> instead of
>>> 
>>> -Dcom.sun.management.jmxremote.ssl=false 
>>> -Dcom.sun.management.jmxremote.port=7091
>>> -Dcom.sun.management.jmxremote.authenticate=false 
>>> 
>>> which is hard to remember, cumbersome to write and error prone since the parameters are not validated. If we are adding support for REST, it could perhaps be default, i.e.
>>> 
>>> -Xmanagement:ssl=false,authenticate=false,port=80
>>> 
>>> If you want to use JMX over RMI you would specify protocol:
>>> 
>>> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi
>> Yes. There is an enhancement request to add the -Xmanagemet:* syntatic sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one of the above flags though I haven't thought of the exact name for it yet. I will update the JEP with the details of the flag shortly. 
>>> 
>>> Has there been any thoughts about JMX notifications?
>> Notifications will not be supported in this JEP. 
>> MBean Notifications are not a widely used feature and will not be supported via the REST adapter.
>>> 
>>> I know it is outside the scope of the JEP, but I think we should take it into consideration when doing the design, so the functionality could be added on later without too much difficulty.
>> Notifications can be added without modifying the current design too much. If required, it will be worked upon via an enhancement request. 
>>> 
>>> Thanks
>>> Erik
>>> 
>> Thanks
>> Harsha
>>>> Hi Martin,
>>>> 
>>>> In my opinion, the interfaces exposed by current JEP are lot closer to REST style than the interfaces exposed by Jolokia. 
>>>> For instance, HTTP GET by default should be used to read resources, but it is made part of URL in Jolokia interfaces.
>>>> 
>>>> <base-url>/read/<mbean name>/<attribute name>/<inner path>
>>>> 
>>>> I would wait on opinions from more people before considering changing the current interfaces.
>>>> 
>>>> Thanks
>>>> -Harsha
>>>> 
>>>> On Wednesday 06 September 2017 11:40 AM, Martin Skarsaune wrote:
>>>>> Hello
>>>>> 
>>>>> Would one at least consider adopting the same URL paths and payloads as Jolokia? This could make life a lot easier for third party tools that connect to it. 
>>>>> 
>>>>> Best Regards
>>>>> 
>>>>> Martin Skarsaune 
>>>>> 
>>>>> ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B <harsha.wardhana.b at oracle.com <mailto:harsha.wardhana.b at oracle.com>>:
>>>>> Hi Kirk,
>>>>> 
>>>>> Yes. Jolokia was considered and is listed as an alternative in the JEP.
>>>>> 
>>>>> Jolokia can serve as a viable alternative but can be bulky. We are looking for simple and lightweight solution.
>>>>> 
>>>>> -Harsha
>>>>> 
>>>>> On Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Have you run into this project? https://jolokia.org <https://jolokia.org/>. Unfortunately it’s not exactly a drop in replacement for the standard RMI based JMX connector but it’s not far off.
>>>>>> 
>>>>>> Kind regards,
>>>>>> Kirk
>>>>>> 
>>>>> 
>>>>>>> On Sep 5, 2017, at 6:30 PM, Erik Gahlin <erik.gahlin at oracle.com> <mailto:erik.gahlin at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Harsha,
>>>>>>> 
>>>>>>> Looping in jmx-dev.
>>>>>>> 
>>>>>>>> byte[], short[], int[], float[], double[]
>>>>>>> Should long[] be included there as well?
>>>>>>> 
>>>>>>>> The REST adapter will come with a simple and lightweight JSON parser.
>>>>>>> Is this an internal parser or will it be exposed as an API?
>>>>>>> 
>>>>>>> If so, how does it relate to JEP 198: Light-Weight JSON API?
>>>>>>> http://openjdk.java.net/jeps/198 <http://openjdk.java.net/jeps/198>
>>>>>>> 
>>>>>>> Will com.sun.net.httpserver.HttpServer be used to serve the requests?
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Erik
>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Please review the JEP for REST APIs for JMX :
>>>>>>>>        https://bugs.openjdk.java.net/browse/JDK-8171311 <https://bugs.openjdk.java.net/browse/JDK-8171311>
>>>>>>>> 
>>>>>>>> The JEP aims at providing RESTful web interfaces to MBeans.
>>>>>>>> 
>>>>>>>> Access to MBeans registered in a MBeanServer running inside a JVM requires a Java client. Language-agnostic access to MBeans will require spawning a Java client which can be cumbersome. The proposed JEP allows MBeans to be accessed in a language/platform-independent, ubiquitous and seamless manner.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> -Harsha
>>>>>>>> 
>>>>>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20170911/a6c558aa/attachment.html>