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?
BTW: jolokia 2.0 will have support for JMX Notifications https://ro14nd.de/jolokia-notifications Best Regards Martin Skarsaune man. 11. sep. 2017 kl. 21:55 skrev Kirk Pepperdine < kirk.pepperd...@gmail.com>: > On Sep 11, 2017, at 9:46 PM, Martin Skarsaune <mar...@skarsaune.net> > 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 > > 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 >>> >>> >>> >>> >> >> >> >> >
