Open tadayosi opened 1 year ago
According to James, Quarkus' support for JMX is minimal since JMX isn't a technology that can run in native mode, and thus necessary MBeans to implement those features might not be available. We might need to reconsider if having the Quarkus plugin for Hawtio really makes sense.
Another thought would be to consider supporting a different backend protocol than JMX (i.e. Jolokia and our JMX plugin) such as Micrometer to achieve the plugin views, but still it's debatable whether it's really worth the efforts.
From what I remember we didn't even consider the native mode, did we?
We didn't. Here we are talking about the case that Quarkus doesn't even provide a set of MBeans about the Quarkus runtime in JVM mode, since investing in them doesn't make much sense for the Quarkus developers.
When thinking about alternative to Jolokia/JMX, I can volunteer to investigate this issue.
Jolokia could still play a role here by providing different, non-JMX based implementation of org.jolokia.service.jmx.api.CommandHandler
or even org.jolokia.server.core.service.request.RequestHandler
.
There's already org.jolokia.support.spring.backend.SpringRequestHandler
that can list/read beans from ApplicationContext. We can do the same with Quarkus/Arc.
Unassigning from myself (for now?) - looks like a big new feature...
Once #31 is done, provide a similar plugin with https://github.com/hawtio/hawtio-next/issues/165 for a Quarkus application. It should as well provide the following views: