I'm wondering if rather than manually writing these MBeans you can use Jackson's ObjectMapper to accomplish the same purpose. Otherwise that's a ton of boilerplate code.

ohh got it, will work over it, to use Jacksons ObjectMapper

I've got a question, do you want an ObjectMapper builder to create these interface ?

Hi Already chnaged all the others comments, the only one pending is this one.

Sorry, busy today.

No specific suggestion here. I'm just thinking from the experience of the oshi-json artifact that maintaining a whole "mirror" of the API is a lot of work. I was hoping ObjectMapper could directly communicate with JMX without coding up the beans.

well, rethinking more about what you had proposed, Im thinking in using ASM with a maven steps in which we can grab all the interfaces on the corresponding classpath, parse those clases into JSON with object mapper and later create the MBeans dinamycaally , so when the strategy for regsitering MBeans is executed, can have those MBenas ref, will work on that

beacuese sadly for JMX we need interface with the suffix MBena and the DynamicMBean would have been a good option but we would need to mantain some enums to specify the operation on each interface and that would end up in the same problem

OK, let's take a step back and make sure we're not trying to solve an X Y problem here.

If JMX interface is limited to creating MBean classes, and we want to reproduce the whole API, then that's a lot of duplicated boilerplate code. Any change to one API has to be made in two places. For the entire 3.x series I maintained the oshi-json tree alongside oshi-core and it was somewhat of a pain. I can imagine a similar issue with MBeans.

We also can trivially generate JSON with Jackson, and return that easily. There's a webserver demo project that gives an idea of capabilities.

So we should scale down and consider JMX only for a subset of the API.

We can still build a JMX interface but we might want to limit it to the stuff that changes regularly, like CPU usage, memory usage, and possibly some process monitoring stuff. For stuff that doesn't change often (or at all), we could just return a JSON string (possibly with a JMX object, or possibly via a separate REST API).

Another approach would be to do some value added to the monitoring. Metrics includes a JMX server and I thought it wold be a great idea. (See #249.) Unfortunately Metrics doesn't handle arrays well and doesn't appear to be actively maintained so it's probably not a good choice. But the idea of building long-running averages of key values and exposing them via JMX or a REST API seems like a great idea. Maybe we could just code up our own server that queries OSHI and calculates some of these metrics (similar to the thread for Windows load averages recently added.)

Well at the end I went with the approach of DynamicMBean and reflection, so it resloves the overhead of creating repetitive code. And for giving the users the capability to know what properties are in each MBena I offer an Interface for giving them the list of props they can retrive for each MBEan

I'm completely in for this effort about creating these servers relying on OSHI and from my perspective that I worked in System Managment systems, it is really hard to find these Open Source efforts well mantained and documented. Actually we struggle a lot with sblim-sfcb beacuse either you need to pay for support at the different Linux distos or you need to have c developers. and thks to you and all this comunity I came up with this awsome library that helped the businnes at that time. And with Converting this into complete server , the posibility are endlees, from either sending threshold event and more. And Regarding this effort, for overcoming the need to construct these interfaces I just implemented and approach with reflection, that way we can have the DynamicMBeams always in sync with watever change is made to the oshi interfaces

Which option do you recommend?

OSHI already has interfaces that define what gets returned, which is essentially how Jackson converts them to its object. The DynamicMBean approach sounds to me like a reasonable option, but you have a lot more experience here so I'd like to hear your thoughts.

OK, let's take a step back and make sure we're not trying to solve an X Y problem here.

If JMX interface is limited to creating MBean classes, and we want to reproduce the whole API, then that's a lot of duplicated boilerplate code. Any change to one API has to be made in two places. For the entire 3.x series I maintained the oshi-json tree alongside oshi-core and it was somewhat of a pain. I can imagine a similar issue with MBeans.

We also can trivially generate JSON with Jackson, and return that easily. There's a webserver demo project that gives an idea of capabilities.

So we should scale down and consider JMX only for a subset of the API.

We can still build a JMX interface but we might want to limit it to the stuff that changes regularly, like CPU usage, memory usage, and possibly some process monitoring stuff. For stuff that doesn't change often (or at all), we could just return a JSON string (possibly with a JMX object, or possibly via a separate REST API).

Another approach would be to do some value added to the monitoring. Metrics includes a JMX server and I thought it wold be a great idea. (See #249.) Unfortunately Metrics doesn't handle arrays well and doesn't appear to be actively maintained so it's probably not a good choice. But the idea of building long-running averages of key values and exposing them via JMX or a REST API seems like a great idea. Maybe we could just code up our own server that queries OSHI and calculates some of these metrics (similar to the thread for Windows load averages recently added.)