I am currently building an application with a REST interface, using Spring Boot, Hibernate and Spring-HATEOAS. My data model is defined as beans with @Entity annotation and I am using Spring's feature to automatically set up a Hibernate repository (Creating an interface extending PagingAndSortingRepository). My application is completely annotation-driven, i.e., I have no web.xml but configure everything with the Spring annotations like @Configuration, @Bean etc., and start the application from my main method with the help of SpringApplication.run(MyApp.class, args);
This works fine, but with this approach, a RepositoryRestHandlerMapping and EndpointHandlerMapping is created. These create a bunch of resources I neither need nor want. I implement my own controllers because they need to do more than the standard logic.
How can I prevent this default behaviour and disable these mappings?
Exclude RepositoryRestMvcAutoConfiguration in your main class.
@EnableAutoConfiguration(exclude = RepositoryRestMvcAutoConfiguration.class)
I need the other REST functions, like @RestController annotation. But I found a feasible solution myself now:
RepositoryRestHandlerMapping should not be disabled, but it is possible to disable exporting of repositories by annotating them with @RepositoryRestResource(exported = false). I did this with all my repositories and now, the wildcard resources are still installed, but no repositories are registered to resolve against them, making them effectively disappear. Trying to access such a resource gives a 404 as expected.
Same for EndpointHandlerMapping, which comes from spring-boot-actuator and installs some endpoints like /info, /metrics etc. This is handy and should be present in a REST application; when I register my application with an Eureka server, it automatically generates links to some of these. To use this correctly, the endpoints can for example be configured via @Bean, like this:
@Configuration
public class InfoConfiguration {
@Bean
public InfoEndpoint infoEndpoint {
Map<String, Object> info = ...
return new InfoEndpoint(info);
}
}
The info above is constant info, if there were info which is subject to change, one could override InfoEndpoint and supply a custom implementation of getAdditionalInfo().
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With