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

[Kirk Pepperdine]

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> 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/3e9d7261/attachment.html>