> On Sep 11, 2017, at 9:46 PM, Martin Skarsaune <[email protected]> wrote:
>
> 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,
I would agree that there are lessons to be learned from Jolokia. It is a
great/useful tool but it is not a JMXConnector. IMHO the REST layer should be
implemented as a JMXConnector. It is the implementation that has the ability to
integrate with widest set of exiting tooling.
Kind regards,
Kirk Pepperdine
> 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
>
> <https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f>
>
> Cheers
>
> Martin
>
>
> man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine <[email protected]
> <mailto:[email protected]>>:
> 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 <[email protected]
>> <mailto:[email protected]>> 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
>>>>> <[email protected] <mailto:[email protected]>>:
>>>>> 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
>>>>>> <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 <[email protected]>
>>>>>>> <mailto:[email protected]> 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 <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
>>>>>>>> <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
>>>>>>>>
>>>>>>>>
>>>>
>>>
>>
>
