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

[Erik Gahlin]

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.

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

Has there been any thoughts about JMX notifications?

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.

Thanks
Erik

> 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. 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
>>>>
>>>>     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
>>>>>
>>>>>     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/47e0fef8/attachment.html>