<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 11, 2017, at 10:30 PM, Martin Skarsaune <<a href="mailto:martin@skarsaune.net" class="">martin@skarsaune.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I can agree to that. To be concrete, what does the JEP as it currently stands offer over jolokia to be able to support JMXConnector? Could the client interface and protocol be two separate concerns? </div></div></blockquote><div><br class=""></div>The interface and the protocol clearly are two separate concerns. The interface in JMX is clearly defined and while the default protocol is RMI, it does not have to be RMI.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">BTW: jolokia 2.0 will have support for JMX Notifications <a href="https://ro14nd.de/jolokia-notifications" class="">https://ro14nd.de/jolokia-notifications</a></div></div></div></blockquote><div><br class=""></div>Yes, my comment in the past has always been… it would be wonderful if jolokia fully supported JMXConnector but unfortunately it doesn’t which means you cannot easily use existing JMX clients with it. Other than that, it’s really useful in environments where using RMI is an issue. I think this where we can learn from jolokia.</div><div><br class=""></div><div>Kind regards,</div><div>Kirk Pepperdine</div><div> </div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Best Regards</div><div class="">Martin Skarsaune </div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">man. 11. sep. 2017 kl. 21:55 skrev Kirk Pepperdine <<a href="mailto:kirk.pepperdine@gmail.com" class="">kirk.pepperdine@gmail.com</a>>:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 11, 2017, at 9:46 PM, Martin Skarsaune <<a href="mailto:martin@skarsaune.net" target="_blank" class="">martin@skarsaune.net</a>> wrote:</div><br class="m_1972803224178586882Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi Harsha and Erik<div class=""><br class=""></div><div class="">I certainly understand the desire to design the API well. </div><div class="">My point was just that when there is a mature battle-tested de-facto solution out in the wild, </div></div></div></blockquote><div class=""><br class=""></div></div></div><div style="word-wrap:break-word" class=""><div class="">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. </div><div class=""><br class=""></div><div class="">Kind regards,</div><div class="">Kirk Pepperdine</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">it would be a pity not to see potential for interoperability where the solutions are in fact really close. </div><div class="">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. </div><div class="">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. </div><div class="">Note: I assumed the arguments are still an array and not an object? ([] , not {}) ?</div><div class=""><br class=""></div><div class="">You can see an example of what changes would typically be needed here:</div><div class=""><a href="https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f" target="_blank" class="">https://github.com/skarsaune/hawtio/commit/36ca65f495f05d20061b001fcc291ed3bc6e183f</a><br class=""></div><div class=""><br class=""></div><div class="">Cheers</div><div class=""><br class=""></div><div class="">Martin</div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">man. 11. sep. 2017 kl. 17:36 skrev Kirk Pepperdine <<a href="mailto:kirk.pepperdine@gmail.com" target="_blank" class="">kirk.pepperdine@gmail.com</a>>:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Hi Harsha,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Consolidating all of the options under a single flag looks like another interesting win.</div><div class=""><br class=""></div><div class="">Kind regards,</div><div class="">Kirk</div></div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 11, 2017, at 4:08 PM, Harsha Wardhana B <<a href="mailto:harsha.wardhana.b@oracle.com" target="_blank" class="">harsha.wardhana.b@oracle.com</a>> wrote:</div><br class="m_1972803224178586882m_-2678713614991453670Apple-interchange-newline"><div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Hi Erik,<br class="">
</p>
<br class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix">On Monday 11 September 2017 07:14 PM,
Erik Gahlin wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix">Hi Harsha,<br class="">
<br class="">
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.<br class="">
</div>
</blockquote>
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. <br class="">
<blockquote type="cite" class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix"> <br class="">
How will the command line look like to start the agent with the
rest adapter?<br class="">
<br class="">
In the past there have been discussions about adding syntactic
sugar for -Dcom.sun.management, i.e.<br class="">
<br class="">
-Xmanagement:ssl=false,port=7091,authenticate=false<br class="">
<br class="">
instead of<br class="">
<br class="">
-Dcom.sun.management.jmxremote.ssl=false <br class="">
-Dcom.sun.management.jmxremote.port=7091<br class="">
-Dcom.sun.management.jmxremote.authenticate=false <br class="">
<br class="">
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.<br class="">
<br class="">
-Xmanagement:ssl=false,authenticate=false,port=80<br class="">
<br class="">
If you want to use JMX over RMI you would specify protocol:<br class="">
<br class="">
-Xmanagement:ssl=false,port=7091,authenticate=false,protocol=rmi<br class="">
</div>
</blockquote>
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. <br class="">
<blockquote type="cite" class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix"> <br class="">
Has there been any thoughts about JMX notifications?<br class="">
</div>
</blockquote>
Notifications will not be supported in this JEP. <br class="">
<ul style="margin:10px 0px 0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">
<li class="">MBean Notifications are not a widely used feature and will not
be supported via the REST adapter.</li>
</ul>
<blockquote type="cite" class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix"> <br class="">
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.<br class="">
</div>
</blockquote>
Notifications can be added without modifying the current design too
much. If required, it will be worked upon via an enhancement
request. <br class="">
<blockquote type="cite" class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix"> <br class="">
Thanks<br class="">
Erik<br class="">
<br class="">
</div>
</blockquote>
Thanks<br class="">
Harsha<br class="">
<blockquote type="cite" class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix"> </div>
<blockquote type="cite" class=""><p class="">Hi Martin,</p><p class="">In my opinion, the interfaces exposed by current JEP are lot
closer to REST style than the interfaces exposed by Jolokia. <br class="">
</p><p class="">For instance, HTTP GET by default should be used to read
resources, but it is made part of URL in Jolokia interfaces.</p>
<pre class="m_1972803224178586882m_-2678713614991453670synopsis" style="font-family:"Lucida Console","DejaVu Sans Mono",Courier,monospace;border-width:1px 1px 1px 0.5em;border-style:solid;border-color:rgb(238,238,238) rgb(238,238,238) rgb(238,238,238) rgb(208,208,208);padding:1em 1.2em;background:rgb(245,245,245);margin-top:0.6em;margin-bottom:0.6em;line-height:17.6px;color:rgb(68,68,68);font-size:14.6667px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><base-url>/read/<mbean name>/<attribute name>/<inner path></pre>
<br class="">
I would wait on opinions from more people before considering
changing the current interfaces.<br class="">
<br class="">
Thanks<br class="">
-Harsha<br class="">
<br class="">
<div class="m_1972803224178586882m_-2678713614991453670moz-cite-prefix">On Wednesday 06 September 2017
11:40 AM, Martin Skarsaune wrote:<br class="">
</div>
<blockquote type="cite" class="">
<div dir="ltr" class="">Hello
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">Best Regards</div>
<div class=""><br class="">
</div>
<div class="">Martin Skarsaune </div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">ons. 6. sep. 2017 kl. 07:04 skrev Harsha
Wardhana B <<a href="mailto:harsha.wardhana.b@oracle.com" target="_blank" class="">harsha.wardhana.b@oracle.com</a>>:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""> Hi Kirk,<br class="">
<br class="">
Yes. Jolokia was considered and is listed as an
alternative in the JEP.<br class="">
<br class="">
<ul style="margin:10px 0px 0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">
<li class="">Jolokia can serve as a viable alternative but can
be bulky. We are looking for simple and lightweight
solution.</li>
</ul>
<br class="">
-Harsha<br class="">
<br class="m_1972803224178586882m_-2678713614991453670m_-2330093802961999704Apple-interchange-newline">
<div class="m_1972803224178586882m_-2678713614991453670m_-2330093802961999704moz-cite-prefix">On
Wednesday 06 September 2017 10:21 AM, Kirk Pepperdine
wrote:<br class="">
</div>
<blockquote type="cite" class="">
<pre class="">Hi,
Have you run into this project? <a class="m_1972803224178586882m_-2678713614991453670m_-2330093802961999704moz-txt-link-freetext" href="https://jolokia.org/" target="_blank">https://jolokia.org</a>. 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
</pre>
</blockquote>
</div>
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<pre class="">On Sep 5, 2017, at 6:30 PM, Erik Gahlin <a class="m_1972803224178586882m_-2678713614991453670m_-2330093802961999704moz-txt-link-rfc2396E" href="mailto:erik.gahlin@oracle.com" target="_blank"><erik.gahlin@oracle.com></a> wrote:
Hi Harsha,
Looping in jmx-dev.
</pre>
<blockquote type="cite" class="">
<pre class="">byte[], short[], int[], float[], double[]
</pre>
</blockquote>
<pre class="">Should long[] be included there as well?
</pre>
<blockquote type="cite" class="">
<pre class="">The REST adapter will come with a simple and lightweight JSON parser.
</pre>
</blockquote>
<pre class="">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?
<a class="m_1972803224178586882m_-2678713614991453670m_-2330093802961999704moz-txt-link-freetext" href="http://openjdk.java.net/jeps/198" target="_blank">http://openjdk.java.net/jeps/198</a>
Will com.sun.net.httpserver.HttpServer be used to serve the requests?
Thanks
Erik
</pre>
<blockquote type="cite" class="">
<pre class="">Hi All,
Please review the JEP for REST APIs for JMX :
<a class="m_1972803224178586882m_-2678713614991453670m_-2330093802961999704moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8171311" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8171311</a>
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
</pre>
</blockquote>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
<br class="">
</blockquote>
<br class="">
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></div></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></blockquote></div>
</div></blockquote></div><br class=""></body></html>