> On Sep 12, 2017, at 12:44 PM, Erik Gahlin <erik.gah...@oracle.com> wrote: > > I guess there are two use cases: > > 1) Simple interoperability with other languages. > 2) A drop in replacement for RMI > > Can a JMX connector be written that support both use cases? I don't know, but > if not it could be that we need both a connector and an adapter.
I think if you were to extend JMXConnector to wrap the REST API you might be able to expose both. But I’m not sure it would be a great solution. I think a second JEP would be a better option. — Kirk > > Erik > >> Hi Kirk, >> >> I guess the term 'connector' here is loosely applied. When I say connector, >> I mean the connector that provides implementation of the package below, >> >> https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html >> >> <https://docs.oracle.com/javase/8/docs/api/javax/management/remote/package-summary.html> >> RMIConnector is one implementation of above connector. >> >> On Tuesday 12 September 2017 12:56 PM, Kirk Pepperdine wrote: >>> 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. >> I hope above should clarify what I refer to when I say JMXConnector. In that >> sense, REST APIs alone cannot work as connector. In fact, it stands parallel >> to connector, as in it directly wraps the MBeanServer and does not wrap any >> JMXConnector. The JEP has detailed information about where the REST adapter >> sits in the JMX architecture. >> >> Are you suggesting that we implement a JMXConnector that works over REST? >>> >>> 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 >> >> Thanks >> Harsha >>> >>> >>> >>>> On Sep 12, 2017, at 9:04 AM, Harsha Wardhana B < >>>> <mailto:harsha.wardhan...@oracle.com>harsha.wardhan...@oracle.com >>>> <mailto: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 < >>>>>> <mailto:harsha.wardhan...@oracle.com>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 < >>>>>>>>> <mailto:harsha.wardhan...@oracle.com>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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
