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
> 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 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
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 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
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,
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
> 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
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 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
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
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 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,
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
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 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
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,
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
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
19 matches
Mail list logo
