From erik.gahlin at oracle.com Tue Sep 5 16:30:49 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 5 Sep 2017 18:30:49 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: Message-ID: <59AED139.4030102@oracle.com> 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 > > From harsha.wardhana.b at oracle.com Wed Sep 6 03:39:00 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 6 Sep 2017 09:09:00 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <59AED139.4030102@oracle.com> References: <59AED139.4030102@oracle.com> Message-ID: <52f0a5e2-1ea1-2443-790f-0c0c4c07a000@oracle.com> Hi Erik, On Tuesday 05 September 2017 10:00 PM, Erik Gahlin wrote: > Hi Harsha, > > Looping in jmx-dev. > > > byte[], short[], int[], float[], double[] > > Should long[] be included there as well? Yes. Thanks. > > > 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? It is an internal parser. > > If so, how does it relate to JEP 198: Light-Weight JSON API? > http://openjdk.java.net/jeps/198 It is written from scratch using JavaCC and is not related to above JEP. > > Will com.sun.net.httpserver.HttpServer be used to serve the requests? Yes. > > > 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 >> >> > - Harsha From harsha.wardhana.b at oracle.com Wed Sep 6 05:03:59 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 6 Sep 2017 10:33:59 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: 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 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 >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Wed Sep 6 06:10:04 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 06:10:04 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: 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.wardhana.b at 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 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 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Sep 6 06:46:55 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 6 Sep 2017 12:16:55 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: 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. /read/// 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 > >: > > 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 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 >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Wed Sep 6 20:46:58 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Wed, 06 Sep 2017 20:46:58 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: How about POST payloads? Since they are so similar already, it would be a huge advantage if they could be made interchangeable. For instance I have done some work on hawt.io plugins. A typical scenario for a plugin is to set up one or more chained requests for read/write/exec on an MBean, and have a callback process the response. If the payloads were compatible, the road to support this new backend might not be too difficult. That would give this new initiative a real boost over traditional JMX connections. Otherwise one would have to impose an additional layer of complexity to bridge the difference. I suppose you know these tools very well already. There is by the way a presentation on JMX, Jolokia and hawt.io at JavaZone in a weeks time, and the recording is usually made available just a few hours later: https://2017.javazone.no/program/bbe08ad550174e16abd954733e018590 Best regards Martin ons. 6. sep. 2017 kl. 08:47 skrev Harsha Wardhana B < harsha.wardhana.b at oracle.com>: > 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. > > /read/// > > > 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.wardhana.b at 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 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 >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Fri Sep 8 03:58:50 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 8 Sep 2017 09:28:50 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: Hi Martin, I will take a second look at POST payloads. Thanks Harsha On Thursday 07 September 2017 02:16 AM, Martin Skarsaune wrote: > How about POST payloads? Since they are so similar already, it would > be a huge advantage if they could be made interchangeable. > > For instance I have done some work on hawt.io > plugins. A typical scenario for a plugin is to set up one or more > chained requests for read/write/exec on an MBean, and have a callback > process the response. If the payloads were compatible, the road to > support this new backend might not be too difficult. That would give > this new initiative a real boost over traditional JMX connections. > Otherwise one would have to impose an additional layer of complexity > to bridge the difference. > > I suppose you know these tools very well already. There is by the way > a presentation on JMX, Jolokia and hawt.io at > JavaZone in a weeks time, and the recording is usually made available > just a few hours later: > https://2017.javazone.no/program/bbe08ad550174e16abd954733e018590 > > Best regards > > Martin > > ons. 6. sep. 2017 kl. 08:47 skrev Harsha Wardhana B > >: > > 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. > > /read/// > > > 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 >> >: >> >> 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 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 >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Mon Sep 11 13:44:22 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 11 Sep 2017 15:44:22 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> Message-ID: <59B69336.7070200@oracle.com> 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. 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 Has there been any thoughts about JMX notifications? 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. Thanks Erik > 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. > > /read/// > > 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 >> >: >> >> 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 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 >>>>> >>>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Mon Sep 11 14:08:59 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 11 Sep 2017 19:38:59 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <59B69336.7070200@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> Message-ID: <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> 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. >> >> /read/// >> >> 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 >>> >: >>> >>> 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 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 >>>>>> >>>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Mon Sep 11 15:35:45 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 11 Sep 2017 17:35:45 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> Message-ID: <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@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 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. >>> >>> /read/// >>> >>> 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 >: >>>> 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 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 >>>>>>> >>>>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Mon Sep 11 19:46:33 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Mon, 11 Sep 2017 19:46:33 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> Message-ID: 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, 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.pepperdine at 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.wardhana.b at 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. > > /read/// > > > 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.wardhana.b at 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 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 >> >> >> >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Mon Sep 11 19:55:49 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 11 Sep 2017 21:55:49 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> Message-ID: <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> > On Sep 11, 2017, at 9:46 PM, Martin Skarsaune 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 >: > 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 > 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. >>>> >>>> /read/// >>>> >>>> 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 >: >>>>> 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 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 >>>>>>>> >>>>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at skarsaune.net Mon Sep 11 20:30:44 2017 From: martin at skarsaune.net (Martin Skarsaune) Date: Mon, 11 Sep 2017 20:30:44 +0000 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> Message-ID: 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.pepperdine at gmail.com>: > On Sep 11, 2017, at 9:46 PM, Martin Skarsaune > 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.pepperdine at 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.wardhana.b at 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. >> >> /read/// >> >> >> 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.wardhana.b at 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 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 >>> >>> >>> >>> >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Mon Sep 11 20:38:31 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Mon, 11 Sep 2017 22:38:31 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <22425ECF-1825-4764-9BBE-EF5A0B7904F7@gmail.com> Message-ID: > On Sep 11, 2017, at 10:30 PM, Martin Skarsaune wrote: > > 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? The interface and the protocol clearly are two separate concerns. The interface in JMX is clearly defined and while the default protocol is RMI, it does not have to be RMI. > > BTW: jolokia 2.0 will have support for JMX Notifications https://ro14nd.de/jolokia-notifications Yes, my comment in the past has always been? it would be wonderful if jolokia fully supported JMXConnector but unfortunately it doesn?t which means you cannot easily use existing JMX clients with it. Other than that, it?s really useful in environments where using RMI is an issue. I think this where we can learn from jolokia. Kind regards, Kirk Pepperdine > > Best Regards > Martin Skarsaune > > man. 11. sep. 2017 kl. 21:55 skrev Kirk Pepperdine >: >> On Sep 11, 2017, at 9:46 PM, Martin Skarsaune > 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 >: >> 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 > 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. >>>>> >>>>> /read/// >>>>> >>>>> 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 >: >>>>>> 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 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 >>>>>>>>> >>>>>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Sep 12 07:04:43 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 12 Sep 2017 12:34:43 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> Message-ID: <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> 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 >> > >> 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. >>>> >>>> /read/// >>>> >>>> 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 >>>>> >: >>>>> >>>>> 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 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 >>>>>>>> >>>>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Sep 12 07:26:55 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Sep 2017 09:26:55 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> Message-ID: 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 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 > 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. >>>>> >>>>> /read/// >>>>> >>>>> 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 >: >>>>>> 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 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 >>>>>>>>> >>>>>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Sep 12 08:40:27 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 12 Sep 2017 14:10:27 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> Message-ID: <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> 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 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 >> > >> 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 >>>> >>> > 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. >>>>>> >>>>>> /read/// >>>>>> >>>>>> 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 >>>>>>> >>>>>> >: >>>>>>> >>>>>>> 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 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 >>>>>>>>>> >>>>>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Tue Sep 12 10:44:12 2017 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 12 Sep 2017 12:44:12 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> Message-ID: <59B7BA7C.5080009@oracle.com> 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. 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 > > 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 >>> > >>> 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 >>>>> >>>> > 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. >>>>>>> >>>>>>> /read/// >>>>>>> >>>>>>> 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 >>>>>>>> >>>>>>> >: >>>>>>>> >>>>>>>> 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 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Sep 12 10:55:18 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Sep 2017 12:55:18 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> Message-ID: <1CF0E23E-387A-41C4-BE9E-2E80424DA4F8@gmail.com> Hi Harsha, > On Sep 12, 2017, at 10:40 AM, Harsha Wardhana B 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk.pepperdine at gmail.com Tue Sep 12 10:57:30 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 12 Sep 2017 12:57:30 +0200 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <59B7BA7C.5080009@oracle.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> <59B7BA7C.5080009@oracle.com> Message-ID: <010313AA-BBA2-4C48-805A-E88FC98AFBD2@gmail.com> > On Sep 12, 2017, at 12:44 PM, Erik Gahlin 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 >> 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 < harsha.wardhana.b at 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.wardhana.b at 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. >>>>>>>> >>>>>>>> /read/// >>>>>>>> >>>>>>>> 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.wardhana.b at 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 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Tue Sep 12 14:16:15 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 12 Sep 2017 19:46:15 +0530 Subject: jmx-dev JEP review : JDK-8171311 - REST APIs for JMX In-Reply-To: <010313AA-BBA2-4C48-805A-E88FC98AFBD2@gmail.com> References: <59AED139.4030102@oracle.com> <59B69336.7070200@oracle.com> <29c25f48-c475-3261-04a7-9797bcbd314e@oracle.com> <61C749ED-D50D-4ABB-8F8A-7327F11AAC81@gmail.com> <74d24494-fef5-9e5d-d3c2-1996ba0e8ff6@oracle.com> <9bae5d49-6f3a-3aca-4635-4b2ec896e14a@oracle.com> <59B7BA7C.5080009@oracle.com> <010313AA-BBA2-4C48-805A-E88FC98AFBD2@gmail.com> Message-ID: Hi Kirk,Erik, The current JEP addresses the first use-case. Second use case can be realized by adding a JMXConnector that operates over REST APIs provided by the current JEP. But that is outside the scope of this JEP. -Harsha On Tuesday 12 September 2017 04:27 PM, Kirk Pepperdine wrote: > >> On Sep 12, 2017, at 12:44 PM, Erik Gahlin > > 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 >>> >>> 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 >>>>> 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 >>>>>>> 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. >>>>>>>>> >>>>>>>>> /read/// >>>>>>>>> >>>>>>>>> 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 >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>> 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 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: