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 MBean
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-
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
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 int
Hi Harsha,
I wouldn’t consider Jolokia to be an alternative because as I suggested, it’s
not a complete JMXConnector implementation and as such cannot be used with
standard JMX clients such as the MBean viewer in JMC or VisualVM. In my
opinion, it would be super if the product of the JEP could
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
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
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
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
Hello
Would one at least consider adopting the same URL paths and payloads as
Jolokia? This could make life a lot easier for third party tools that
connect to it.
Best Regards
Martin Skarsaune
ons. 6. sep. 2017 kl. 07:04 skrev Harsha Wardhana B <
harsha.wardhan...@oracle.com>:
> Hi Kirk,
>
> Y
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
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
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 compli
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
> 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 fr
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
B
> 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 protoco
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
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-
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 conn
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 '
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/ma
> 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 b
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:
O
24 matches
Mail list logo
