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 <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 >>>>> <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 <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 >>>>>>> >>>>>>> >>> >> >
