Hi Harsha, From Chapter 5 of the JMX documentation. "Many different implementations of connectors are possible. In particular, there are many possibilities for the protocol used to communicate over a connection between client and server.”
It goes on in the Generic Connector section under "User-Defined Protocols” to say; "While the RMI connector must be present in every implementation of the JMX Remote API, you can also implement a connector based on a protocol that is not defined in the JMX Remote API standard. A typical example of this is a connector based on a protocol that uses HTTP/S. Other protocols are also possible. The JMX specification describes how to implement a connector based on a user-defined protocol.” Unless I’m missing something, this all suggests that there is nothing inherently wrong is using REST behind a JMXConnector. As written this JEP pretty much looks like Jolokia. Jolokia is a great project and as such I fail to see the benefits of simply duplicating it. I’d also argue that the usefulness of that project has been some what muted because it is not a drop in replacement for the standard RMI connector meaning that one has to modify an entire tool chain just to make use of it. However, creating a REST based JMXConnector would be immediately useful. As an aside, Jus last week I started on a JMXConnector that uses a shared memory segment for communications. Of course this implementation would only be available for local communications but it offers some advantages over using a socket based protocol, even if that comms is over local loopback. Kind regards, Kirk Pepperdine > On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B <harsha.wardhan...@oracle.com> > wrote: > > Hi Kirk, > > REST APIs work as an adapter and cannot work as a connector. To quote from > the JEP, > > >> The REST adapter is a part of the Distributed services level. Connectors >> mirror the interfaces of agent level services to remote clients, whereas >> adapters transform agent level services to different protocol. The proposed >> functionality will transform Agent level services to REST APIs, hence the >> name "REST adapter". > A connector *must* adhere to the JMX remoting spec. REST APIs cannot adhere > to that because they expose APIs via HTTP and not Java. Hence it is called an > Adapter and not a connector. It can never work as a 'drop-in' replacement for > JMX/RMI Connector. Existing tools using using RMIConnector will have to be > modified to use REST APIs. > > The current JEP does not allow all of the CRUD operations on MBeans. In the > spirit of keeping the APIs language agnostic, only read/write is supported. > It is not possible to specify create/delete REST APIs for JMX without > incorporating language specific features. I would welcome discussions around > including create/delete APIs for MBeans. > In lieu of the above, as of now REST adapter cannot exist independently and > will have to live along-side RMIConnector. > -Harsha > > On Monday 11 September 2017 09:05 PM, Kirk Pepperdine wrote: >> 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 <mailto: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 >>>>>>>>> >>>>>>>>> >>>>> >>>> >>> >> >
