Hi Harsha,
> On Sep 12, 2017, at 10:40 AM, Harsha Wardhana B > <harsha.wardhan...@oracle.com> wrote: > > 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. > Yes, this is the precise definition that I’ve been referring to. > > 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. Indeed it cannot because they are not part of the JMXConnector API. Ok, I reread and see I misunderstood the use cases that you’re trying to cover off. It seems you’re only goal is to duplicate Jolokia whereas I’m looking at a different use case. The primary use case I encounter is motivated by the inability of various sites to use JMX simply because of the operational restrictions that prevent them from using RMI. This JEP will help with that use case. That said, adding a JMXConnector with a RESTful JMXConnector would open up an entire JMX tool chain to them rather than have them have to define a new tool chain but this is outside the scope of this JEP. > 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? Yes, adding a JMXConnector with a RESTful JMXConnector would open up an entire JMX tool chain to them rather than have them have to define a new tool chain but this appears to be outside the scope of this JEP. Kind regards, Kirk
