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.wardhan...@oracle.com <mailto: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 <mailto: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>
<mailto: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