martint
commented
11 years ago I did find that it was missing the ability to specify name/description for operation names (or for that matter the mbeans themselves). This is minor IMO for mbeans themselves, though nice to have, but for operations is often hard to figure out what the parameters are for with the default names, so I think its important to allow that metadata to get expressed.
Agreed. It shouldn't be hard to add those.
Also, any idea how difficult it would be to allow an object instance to inform the library what objectname it should use, or to perhaps even delegate the mbean class which should provide jmx access for it? And really I'm taking more about the guice integration (which is really great btw), but it looks like it binds the mapping to strings very early, before an instance is ever created.
That should also be straightforward. There's an experimental API I've been working on (it's already in master) to export maps and sets of objects, where the name of each object is determined dynamically via a user-provided callback. It should be easy to extend to export single objects, too.
Also, any ideas on how to expose javabean values as openmbean datatypes similar to how MXBeans do? I see there is @flatten and @Nested which is nice, but it would be nicer if it would just translate on the fly to openmbean data formats like MXBeans do.
That will probably require a lot more surgery. I need to look into it...
jmxutils is pretty nice :-)
I did find that it was missing the ability to specify name/description for operation names (or for that matter the mbeans themselves). This is minor IMO for mbeans themselves, though nice to have, but for operations is often hard to figure out what the parameters are for with the default names, so I think its important to allow that metadata to get expressed.
Also, any idea how difficult it would be to allow an object instance to inform the library what objectname it should use, or to perhaps even delegate the mbean class which should provide jmx access for it? And really I'm taking more about the guice integration (which is really great btw), but it looks like it binds the mapping to strings very early, before an instance is ever created.
Also, any ideas on how to expose javabean values as openmbean datatypes similar to how MXBeans do? I see there is @Flatten and @Nested which is nice, but it would be nicer if it would just translate on the fly to openmbean data formats like MXBeans do.
Anyways, just some thoughts... if you have any ideas I'd like to hear them. I might get inspired to go hack this stuff in.