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