Hi Harsha and Erik
I certainly understand the desire to design the API well.
My point was just that when there is a mature battle-tested de-facto
solution out in the wild, it would be a pity not to see potential for
interoperability where the solutions are in fact really close.
To illustrate where I'm coming from, I hacked the source of a plugin that
is able to control the flight recorder via JMX , to adapt the POST payloads
to this JEP.
Assuming I understood it correctly the changes are quite small, but would
the require a complete rewrite of all plugins, a layer of indirection or
even worse a compatibility layer to use it.
Note: I assumed the arguments are still an array and not an object? ([] ,
not {}) ?
You can see an example of what changes would typically be needed here:
https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f
Cheers
Martin
man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine <
kirk.pepperd...@gmail.com>:
> Hi Harsha,
>
> The only reason I mentioned Jolokia is that it’s a project that usefulness
> is some what limited because it is *not* a compliment JMX connector and as
> such cannot be used as a straight drop-in replacement for the current RMI
> based connector. Is your plan here to make it a fully compliant connector
> so that we could configure tooling such as the MBean viewers in jConsole
> and VisualVM (or JMC for that matter) to use a restful connector instead of
> an RMI based connector? IMHO, doing so would represent a huge win as I know
> of quite a few projects that cannot or will not use JMX because of it’s
> reliance on RMI.
>
> Consolidating all of the options under a single flag looks like another
> interesting win.
>
> Kind regards,
> Kirk
>
>
>
> On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B <
> harsha.wardhan...@oracle.com> wrote:
>
> Hi Erik,
>
> On Monday 11 September 2017 07:14 PM, Erik Gahlin wrote:
>
> Hi Harsha,
>
> I haven't looked at Jolokia, or know what is the most reasonable approach
> in this case, but as a principle, I think we should strive for the best
> possible design rather than trying to be compatible with third party tools.
>
> Agreed. That will always be the first priority. That is the reason HTTP
> GET interfaces will not be changed. I am undecided if the POST payloads
> need to be changed (without compromising the REST design principles) to
> increase adoption of this feature.
>
>
> How will the command line look like to start the agent with the rest
> adapter?
>
> In the past there have been discussions about adding syntactic sugar for
> -Dcom.sun.management, i.e.
>
> -Xmanagement:ssl=false,port=7091,authenticate=false
>
> instead of
>
> -Dcom.sun.management.jmxremote.ssl=false
> -Dcom.sun.management.jmxremote.port=7091
> -Dcom.sun.management.jmxremote.authenticate=false
>
> which is hard to remember, cumbersome to write and error prone since the
> parameters are not validated. If we are adding support for REST, it could
> perhaps be default, i.e.
>
> -Xmanagement:ssl=false,authenticate=false,port=80
>
> If you want to use JMX over RMI you would specify protocol:
>
> -Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi
>
> Yes. There is an enhancement request to add the -Xmanagemet:* syntatic
> sugar for -Dcom.sun.management.jmxremote.* flags. REST adapter will use one
> of the above flags though I haven't thought of the exact name for it yet. I
> will update the JEP with the details of the flag shortly.
>
>
> Has there been any thoughts about JMX notifications?
>
> Notifications will not be supported in this JEP.
>
> - MBean Notifications are not a widely used feature and will not be
> supported via the REST adapter.
>
>
> I know it is outside the scope of the JEP, but I think we should take it
> into consideration when doing the design, so the functionality could be
> added on later without too much difficulty.
>
> Notifications can be added without modifying the current design too much.
> If required, it will be worked upon via an enhancement request.
>
>
> Thanks
> Erik
>
> Thanks
> Harsha
>
> 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
>>
>>
>>
>>
>
>
>
>
