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