It looks like it should live in org.springframework.boot.actuate.autoconfigure.metrics.web.

Comment From: mbhave

Placing on hold till #14860 is sorted.

Comment From: nishantraut

Hi @mbhave This looks simple moving class from old package to new mentioned above. Please let me know once this issue is removed from hold state. Will be happy to work on this. Thanks.

Comment From: wilkinsona

Flagging for team attention so that we can consider doing this in 3.0 without #14860.

Comment From: wilkinsona

This is blocked until we've reinstated support for Jersey which should be possible once 3.1 has been released.

The main Jersey auto-configuration is in org.springframework.boot.autoconfigure.jersey so the current location of JerseyServerMetricsAutoConfiguration – org.springframework.boot.actuate.autoconfigure.metrics.jersey – feels right to me. If we moved the metrics auto-configuration to org.springframework.boot.actuate.autoconfigure.metrics.web then I wonder if JerseyAutoConfiguration should move too.

Comment From: mbhave

I think I might've seen that the actuator auto-configuration is under org.springframework.boot.actuate.autoconfigure.web.jersey when I logged this issue. That's also a bit odd because there's org.springframework.boot.actuate.autoconfigure.web.servlet which has MVC-related classes but could have jersey?

JerseyApplicationPath and DefaultJerseyApplicationPath are in org.springframework.boot.autoconfigure.web.servlet which also seems inconsistent.

Comment From: wilkinsona

Thanks, @mbhave.

org.springframework.boot.actuate.autoconfigure.web.servlet is named after org.springframework.web.servlet which is the root package for Spring MVC. As such, I don't think Jersey-related code belongs in a web.servlet package.

org.springframework.boot.actuate.autoconfigure.web.jersey is the auto-configuration for the actuator's web endpoint infrastructure when running on top of Jersey. There are .servlet and .reactive packages here too for the MVC and WebFlux support. We also have org.springframework.boot.actuate.autoconfigure.endpoint.web.jersey (and .servlet and .reactive variants as well). We only have one class in each of these packages. The distinction between .endpoint.web.<framework> and .web.<framework> isn't very clear to me. It's all code for running Actuator on top of a particular framework. I wonder if they could be combined.

The location of JerseyApplicationPath and DefaultJerseyApplicationPath does seem inconsistent. I think they should both be in the same package as the rest of the Jersey auto-configuration. That's org.springframework.boot.autoconfigure.jersey at the moment.

It looks to me like that are two, somewhat separate packaging questions here:

  1. Do we need the separate org.springframework.boot.actuate.autoconfigure.web.<framework> and org.springframework.boot.actuate.autoconfigure.endpoint.web.<framework> packages?
  2. Is org.springframework.boot.autoconfigure.jersey the right package for the Jersey auto-configuration?

The answers to these will then have a knock-on effect on the two groups of Jersey-related packages:

  1. Code in support of using and observing Jersey in an application
  2. Code in support of running Actuator on top of Jersey

Comment From: bclozel

While discussing this issue, we've found new candidates for relocation/renaming.

  • we are wondering if we should split the existing org.springframework.boot.actuate.autoconfigure.web package and create a new org.springframework.boot.actuate.autoconfigure.infrastructure package
  • we also noticed ServletEndpointManagementContextConfiguration in org.springframework.boot.actuate.autoconfigure.endpoint.web; it is using the ManagementContextConfiguration and referring to both Spring MVC and Jersey