Allow JMX endpoint ObjectNames to be customized by providing an EndpointObjectNameFactory bean

[manueljordan]

Hello SB developers.

Just being curious and how a friendly suggestion and request.

If is possible change the name of an endpoint available through HTTP through

management.endpoints.web.path-mapping.info=information
management.endpoints.web.path-mapping.health=salud

Why not make available the same approach for JMX?, something like:

management.endpoints.jmx.mbean.info=information
management.endpoints.jmx.mbean.health=salud

I know it is not critical, but because it is available through Web. Why not give the developer or oversight the option to have HTTP and JMX keeping the same names.

Thanks for your understanding

[wilkinsona]

We allow the endpoints paths to be changed when using HTTP for a couple of reasons:

1. To match the path to the requirements of a general monitoring solution
2. When configuring the base path to / to avoid a clash with one of the application's own endpoints

When using JMX, I don't think either of these needs exists. The MBeans are specific to Spring Boot so any monitoring tool that's querying them will also have to be, in part, Spring Boot specific as well. There's also no possibility of a clash as the MBean's are published with the org.springframework.boot domain.

We generally expect applications to be monitored using either JMX or HTTP so hadn't considered a need for consistent naming between the two. Do you have a particular need for them to be able to match?

[manueljordan]

Hi @wilkinsona

No particular critical reason, but in some unusual scenario, if we have two oversight working in http and jmx in the same time and each one through a different branch/option, and by remote, they would need coordinate to access to the same endpoints based with the same names.

Of course it is not critical, but would be a valid scenario, not very usual, but would happen.

I know, it is a trivial request.

If you want, proceed to close this issue.

[wilkinsona]

Thanks, @manueljordan.

We have an EndpointObjectNameFactory strategy interface that's used to create the ObjectName for each endpoint MBean. We don't, however, allow you to provide your own implementation. I'm not sure that this is a sufficiently common requirement that we should provide configuration properties for it, but it would be a small change to allow an EndpointObjectNameFactory to be provided as a bean. Let's see what the rest of the team thinks.

[manueljordan]

Sounds great @wilkinsona !

Other reason is when a nice project manager in his infinite wisdom wants all the endpoints in Spanish - or perhaps - French, Portuguese

I think the point is have this approach available to bring flexibility ... I know is not critical, is trivial, but would be a possible requirement at some point of time.

[snicoll]

Exposing a way to customize the EndpointObjectNameFactory sounds good to me. However, I am wondering how practical this would be without making DefaultEndpointObjectNameFactory public somehow.

[mbhave]

Can we expose it via a property that DefaultEndpointObjectNameFactory would consume instead?

[snicoll]

A property that defines what part exactly? The ObjectName is quite complex so I am not sure that I'd want that in properties.

[mbhave]

oh I thought we wanted to make just the name part configurable. But maybe I've misunderstood the issue.

[snicoll]

Thanks for confirming. That's what I was suspecting what you were referring to. IMO if we offer a way to customise this, we should aim at the objectname, not a part of it.

[philwebb]

We're going to makeEndpointObjectNameFactory a bean that you can add yourself. We won't make DefaultEndpointObjectNameFactory public because we think generally it's not a good idea to rename the JMX beans (for example, IDE tooling often needs specific names).

[manueljordan]

we think generally it's not a good idea to rename the JMX beans (for example, IDE tooling often needs specific names)

It is about any domain created by the same Java Application, right?. If I am not correct, expand pls a little more the idea.

The goal with the original post is only edit or rename any MBean available only within the org.springframework.boot domain. Has no sense change the other domains available within the same App

[wilkinsona]

IDE tooling uses the MBeans provided by the Actuator to display information about your app. If you rename them, that tooling will break.

[manueljordan]

I understand now, thanks for the clarification, why not use a kind of alias? Keep the original name for the IDE (nothing is break) and apply the alias (through a special annotation) and a flag set to true to enable recognize that annotation, through a property defined in application.properties, to let JConsole/VisualVM use that alternative/alias value.

[snicoll]

@manueljordan we've already described what our plan is, see this comment above. As we don't think it's not a good idea to rename the JMX beans, we won't provide such first class support for it.

[manueljordan]

Hello @snicoll - Yes, it only was a thought. That's all and understood