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 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 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.wardhan...@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.wardhan...@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.gah...@oracle.com> >> <erik.gah...@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 >> >> >> >> >
