Spring-boot: Change /application as the root actuator path to /actuator

[philwebb]

6886 introduced /application as the root path for actuator endpoints. We didn't really capture in that issue why /application was picked and a few internal discussion mean we should evaluate if it's really the right call.

Snippets from the Slack conversion --

From @ghillert:

For _Spring Cloud Skipper_ we want to be as much aligned with Boot 2.0 as possible.

Just had a quick discussion with @markpollack and @mfisher and in our case /application may not create enough visual distance between application specific endpoints and Boot’s endpoints and feel that this might be a possible issue with possible end-users of Boot as well. In our case, we may consider using /actuator instead.

From @markfisher:

To add to what Gunnar is saying, that was my initial impression with the actuator endpoint change. If the purpose of a dedicated top level endpoint is to avoid collisions with application mappings, then maybe that itself should be called something other than /application. We were thinking /actuator is a great name for it, since nobody seems to know what it means and therefore the likelihood of collisions is near zero

From @dsyer:

+1 to that (not using /application as the default that is)

[philwebb]

There were a number of reasons for wanting to move all endpoints under a common root. The most obvious one was it's easier to understand and secure actuator paths if they all start with the same thing.

There was also a desire to reduce the likelihood of collisions with the users own mappings, but this consideration was mainly about reducing the number of collisions, not necessarily picking a unique name. In other words, in 1.5 a user needed to worry about all the endpoints (/health, /env, /beans) where in 2.0 they just need to worry about one. The single root also makes upgrades easier. We can add new endpoints without as much fear that the new path will already be in use.

We considered quite carefully what the root endpoint path should be. Using /actuator was the most obvious choice, but there are a few issues with it:

• Nobody seems to know what it means. That's not so bad for the JAR name because we can educate Spring Boot users, but once it's in a URL, non-developers are going to need to learn the term.

• We don't really expose "actuator" as a term in other parts of Boot. This is sort of related to the above. Other than the JAR, we don't use it in configuration properties or user-facing class names.

• It sounds a little confusing when you try and talk about a URL. For example, would actuator/beans show all beans, or just beans that the actuator uses? Is /actuator/env talking about my application environment, or just the actuator bits. If you compare this to /application/beans, /application/env, /application/health there's a lot less ambiguity. It's clear (even to someone that isn't a Spring Boot user) that /application/health probably shows the health of the running application.

On the whole, /application seemed a lot less problematic. The biggest concern we had with /application was that someone would want it for their own URLs. This could be an issue but:

• It's pretty easy to either change ours or pick a different one yourself.

• Most Spring Boot apps (that I've seen) have a single DispatcherServlet mapped to / and rely on top level MVC mappings. Having multiple servlets exposed directly and needing to pick a catch-all name for the DispatcherServlet is pretty rare.

[philwebb]

OK, we discussed this in our call and we'll rename it to /actuator

[gajanan999]

why Spring 2.0.0.RELEASE is not working with

<dependency>
          <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
 </dependency>

it gives me the following error
Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.databind.AnnotationIntrospector
at java.net.URLClassLoader.findClass(Unknown Source) ~[na:1.8.0_112]
at java.lang.ClassLoader.loadClass(Unknown Source) ~[na:1.8.0_112]
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) ~[na:1.8.0_112]

[wilkinsona]

@gajanan999 You may have a corrupted jar but that’s unrelated to this issue. Please ask questions on Gitter or Stack Overflow.

[gajanan999]

@wilkinsona Thank you for replying, but i have solved the issue by overriding the com.fasterxml.jackson.core/jackson-databind to 2.9.5
Solved solution :

com.fasterxml.jackson.core
jackson-databind
2.9.5

2.9.4 to 2.9.5

[wilkinsona]

That fits with my guess that you had a corrupted jar. Using a different version will have caused a new jar to be downloaded.