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




Reply via email to