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

Harsha Wardhana B harsha.wardhana.b at oracle.com
Fri Sep 8 03:58:50 UTC 2017


Hi Martin,

I will take a second look at POST payloads.

Thanks

Harsha


On Thursday 07 September 2017 02:16 AM, Martin Skarsaune wrote:
> How about POST payloads? Since they are so similar already, it would 
> be a huge advantage if they could be made interchangeable.
>
> For instance I have done some work on hawt.io <http://hawt.io> 
> plugins. A typical scenario for a plugin is to set up one or more 
> chained requests for read/write/exec on an MBean, and have a callback 
> process the response. If the payloads were compatible, the road to 
> support this new backend might not be too difficult. That would give 
> this new initiative a real boost over traditional JMX connections.
> Otherwise one would have to impose an additional layer of complexity 
> to bridge the difference.
>
> I suppose you know these tools very well already. There is by the way 
> a presentation on JMX, Jolokia and hawt.io <http://hawt.io> at 
> JavaZone in a weeks time, and the recording is usually made available 
> just a few hours later: 
> https://2017.javazone.no/program/bbe08ad550174e16abd954733e018590
>
> Best regards
>
> Martin
>
> ons. 6. sep. 2017 kl. 08:47 skrev Harsha Wardhana B 
> <harsha.wardhana.b at oracle.com <mailto:harsha.wardhana.b at oracle.com>>:
>
>     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/20170908/57e64d24/attachment.html>


More information about the serviceability-dev mailing list